Replies: 20 comments 32 replies
-
Could we enforce a max gas limit per tx instead of per block for chains interested in scaling the block gas limit, but also interested in remaining interoperable? |
Beta Was this translation helpful? Give feedback.
-
|
Interesting idea - I don't see any truly inherent problems with allowing chains with different gas limits to be interoperable. There are other cases in which execution isn't fungible between chains, for example one chain may have state that another chain doesn't have. The free market should be able to solve the problem where a transaction consumes more than the gas limit on one chain but within the gas limit on another chain. Either the smaller chain increases its gas limit to compete for fees the tx provides or the tx specializes towards executing on the chain with the larger gas limit. If we did enforce a max gas limit per tx it would ensure that all transactions can execute everywhere but 1) this limits possible future use cases where large amounts of gas are required and 2) still doesn't solve the state is only on one chain issue. I think that there is some inherent non fungibility of execution due to state and we should accept that gas limit is another variable between chains. As long as this non fungibility can be made legible at the application layer, we can ensure that applications can be built securely between non fungible block space. |
Beta Was this translation helpful? Give feedback.
-
|
There are already interoperability solutions, e.g. my NFTs in OP can I send them to Polygon and/or Avalanche and vice versa? |
Beta Was this translation helpful? Give feedback.
-
|
This interoperability solution is specifically for OP Stack based chains. It will not work for Polygon or Avalanche or any other non OP Stack based chain. |
Beta Was this translation helpful? Give feedback.
-
|
GM @tynes Thanks for the FAQs.
In the current setup (without interop specs), there are no trust assumptions from the rollup nodes, are there? They get a block full of transactions signed by the sequencers and all they have to do is execute them and publish the state root to Ethereum. In the new design, there seems to be some trust assumptions introduction if I'm understanding it correctly. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @sandman2797. Good questions
|
Beta Was this translation helpful? Give feedback.
-
|
There is a lot of commits to the Would be awesome to also have a small bullet point list of files that are worth diving into. |
Beta Was this translation helpful? Give feedback.
-
|
We are actively working on reducing the size of diffs when shipping features so its easy to understand directly what is going on. I recommend checking out |
Beta Was this translation helpful? Give feedback.
-
Only EOA Invariant + EIP 3074Edit: latest information can be found here EIP 3074 is CFI for the Prague hardfork. This EIP renders the "only EOA" invariant impossible to enforce, meaning that it is no longer possible to statically analyze the transactions that call the This enables smart contract wallets or 4337 bundlers to submit executing messages which is a huge win for UX. It should now be possible to create a paymaster for sending particular types of executing messages. This also increases the cost of a block builder and the architecture of the block builder needs to be resilient to denial of service. Previously, no execution was required to know if an executing message was invalid, it could be determined statically by simply observing the calldata. Now execution is required to determine if any transaction is valid. The particular denial of service that we want to avoid is forcing the block builder to do a lot of work to ultimately not be able to include a transaction. Block builders can likely find heuristics that eliminate these denial of service attacks while still processing all normal usage. We also want to avoid execution in the mempool. We could leverage the |
Beta Was this translation helpful? Give feedback.
-
|
See specs PR that addresses these concerns: #149 |
Beta Was this translation helpful? Give feedback.
-
|
Some follow up design thoughts on how we can safely handle deposits while removing the only EOA invariant are here: ethereum-optimism/design-docs#13 |
Beta Was this translation helpful? Give feedback.
-
|
Is there more information about the superchain ERC20 specification? Does this mean that the intention is to have canonical ERC20s be movable via burn-mint between superchains over this interop layer? |
Beta Was this translation helpful? Give feedback.
-
|
The superchain ERC20 standard is being iterated on in the following PR: #71 We would like to spike what it would look like to use xERC20 vs yet another standard that we create before moving forward with it. |
Beta Was this translation helpful? Give feedback.
-
|
Where does the code for the |
Beta Was this translation helpful? Give feedback.
-
|
A prototype can be found in ethereum-optimism/optimism#9612 with some additional work in ethereum-optimism/optimism#10044. Since #128 (comment) the |
Beta Was this translation helpful? Give feedback.
-
|
See the design doc for the superchain backend here: ethereum-optimism/design-docs#9 |
Beta Was this translation helpful? Give feedback.
-
|
The superchain backend is now called |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to assign varying degrees of safety requirements to chains in the dependency set? Clearly there is good reason to limit the dependency set form which unsafe messages are accepted, but it seems reasonable that a chain might want to allow messages from any other OP chain once finalized. |
Beta Was this translation helpful? Give feedback.
-
|
We purposefully do not add this complexity to the protocol itself and leave it to the block builder to develop a policy in which they are comfortable with. When accepting an executing message, there is inherent risk tied to the finality of the initiating message. There may be some chains that are known to have better finality properties than others (ie fast batch submission). It is up to the sequencer (who is the block builder) to choose when to include messages and they have the right to treat different chains differently. This needs to be handled in a special case for deposit transactions that are executing messages, since those are force include. We will need special logic to handle those, likely the rule will be a sequencer window must pass on top of the initiating message for the deposited executing message to be considered valid, otherwise you could force reorgs or chain splits via deposits. |
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone, looking forward to contribute here from Gelato's side. Would love to have further feedback sessions with your team here, given our long experience building on-chain systems that rely on Relayers or Keepers. We learnt many things along the way regarding efficiency and MEV protection. For example, saw in the spec somewhere that Relayer permissioning should not be enabled and, instead, a fee to tx.origin should be paid as MEV to open up the Relayer role to anyone. Problem with that is that this might lead to malicious sniping/frontrunning of legit Relayer txs. We had this issue with Connext early on, which lead to super high MEV costs for us that were paid in reverted txs and the frontrunner took the profit. Also, I understand that currently the spec only allows for EOAs to execute the messages. I understand this has smth to do with static analysis of calldata. This is quite restrictive though and our current Relay system usually routes via Gelato smart contract middleware, to take care of things like our decentralized relayer consensus protocol (making sure Gelato nodes dont collide with each other on executions), but also about important oracle-like tasks, such as reporting a fair gas price and token conversion rate on-chain, for dealing with messages that pay the relayer synchronously for gas expenditure in tokens. Gelato's system passes this price info in calldata too, but it is ratified by a smart contract off-chain signature first. This would not be an issue for our 1balance sponsoredCall, which uses Gelato 1Balance to handle all Relayer payments off-chain (super neat feature for multi-chain Relayer payment automation and efficiency btw). Anyways, have you considered such more complex Relayer systems that involve synchronous on-chain relayer payments support by smart contract middleware intercepting the message execution? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @gitpusha, thanks for checking out the spec. I would like to clarify that the "only EOA" invariant is being removed as the possible inclusion of 3074 removes the ability to enforce such an invariant. You can see an update here: #128 (comment). We can prioritize merging #149 and capture its considerations in a follow up task to ensure that up to date information is in the specs.
This sounds like your expertise, I am just interested in building simple yet powerful abstractions that can enable these more complex relayer systems :) Given the spec changes to remove the "only EOA" invariant, do you have any other considerations? |
Beta Was this translation helpful? Give feedback.
-
|
#149 has been merged so now the specs should be up to date with the removal of the "only EOA" invariant |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, thx @tynes !
A further consideration would be any opinions about Relayer payments or permissioning in your spec/code. I am not sure right now and dont have time to check, but I believe I saw somewhere that you were considering enforcing something there, or is all relayer payment handling left to the Relay system and not part of this spec? |
Beta Was this translation helpful? Give feedback.
-
|
Cant wait to slap Gelato Relay on top of this btw! |
Beta Was this translation helpful? Give feedback.
-
This is the case, the lowest level abstractions are not opinionated and are also |
Beta Was this translation helpful? Give feedback.
-
|
Suggestion: Expand the This way the predeploy can be the canonical method to permissionlessly consume the state of a remote chain without requiring a 3rdparty initiating message |
Beta Was this translation helpful? Give feedback.
-
|
Working on this diagram to visualize the flow of the system. The block builder and the sequencer can be the same entity but they do not need to be. sequenceDiagram
User->>Block Builder: Sends executing message
Block Builder->>Superchain Backend: Checks validity of message
Superchain Backend->>Block Builder: Yes is valid
Block Builder->>Block Builder: Create block
Block Builder->>Sequencer: Commit to this block
Sequencer->>Ethereum: Publish Data
|
Beta Was this translation helpful? Give feedback.
-
|
Hello @tynes thanks for these FAQs, I have a couple questions:
thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Hey @ricott1, thanks for checking out the spec.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your answer 🙏 With my second question I meant something different, I'll try to rephrase and split it into sub-questions.
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @tynes, did you have time to go over these other questions? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Given #128 (comment) and ethereum-optimism/design-docs#13, there is no longer a need for static analysis on the transactions that trigger executing messages. This means that the The following function proposed by @skeletor-spaceman may be useful for developers building applications on top of interop. We need to be mindful of feature bloat, but we could certainly add this function if it makes the lives of app devs easier. function validateMessage(Identifier calldata _id, bytes calldata _message) external {
if (_id.timestamp > block.timestamp) revert InvalidTimestamp();
if (!IDependencySet(Predeploys.L1_BLOCK_ATTRIBUTES).isInDependencySet(_id.chainId)) {
revert InvalidChainId();
}
emit ExecutingMessage(abi.encode(_id), _message);
} |
Beta Was this translation helpful? Give feedback.
-
|
What if we modified the spec such that including an invalid executing message doesn't result in an entire block being reorg'd out but instead the transaction that triggered the executing message is mapped into a noop transaction? The exact semantics of a noop transaction need to be defined (they were explored in ethereum-optimism/design-docs#13). This would either require a diff to the EVM or some sort of magic by the L1 attributes transaction. The problem with the L1 attributes transaction approach is that it would be modifying the transaction based on execution that comes after it, so we would need to follow an approach where the L1 attributes transaction now includes information about the execution of the previous block. The whole idea of mapping executing messages to noops if they are invalid is to derisk large reorgs. It may lighten the dos vector on the sequencer, but they would still need to double check the executing messages before including them because any reorg is a quality of service issue, even if its a relatively small one. It seems generally more simple to just call the entire block invalid when there is a single executing message that is invalid. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @tynes thanks for starting the Q&A, a few questions: Within a dependency set graph, do all chains share their chain security? For example, chain A -> chain B, chain B->C. So A,B,C are in one dependency set. Is there anything that stops chain C from adding to its dependency set without A and B acknowledging? If not, isn't it a concern where if any chain above your chain in the dependency set adds a dependency, your chain is automatically tied to it in security? For example chain C adds D so C->D, but D ends up getting corrupted, D will be able to send any message to chain A to access it's funds and How are fees associated with relaying the cross-chain messages paid to the relayers? Does message delivery have to be guaranteed before releasing those fees to the relayer? If yes, how is a receipt provided to verify that the message delivery was successful to pay the corresponding relayer fees. Is there any possible alternate design where any chain can deliver cross-chain messages permissionlessly to any other chain. The cross-chain message needs to be checked to have an initiated message from the source chain, and that initiation message must be validated from the source chain's validator set. Then dApps can restrict access from specific source chain messages if they'd like. |
Beta Was this translation helpful? Give feedback.
-
|
hey @minghinmatthewlam ! great questions :)
the short answer here is yes, but the application layer can be built to identify as the interop protocol is concerned, events would be valid to reference, but the application will revert if they have a not-yet-trusted
relayer fees are NOT enshrined at the protocol level, this should be develop at the application layer. This is a VERY interesting design space. see the comment below ;)
100%! we will definitely see chains that will have it's sequencer act as an Interop relayer for all or specific events. |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense, essentially dApps would be able to, and also have a responsibility, of checking the source of the originating message, and add it checks if they would like additional restrictions on the sub-dependency set. I agree that this interop can be seen as UDP, and that additional abstractions can be built on top to simulate TCP. But for UDP isn't relaying built in natively? Curious what the considerations were when deciding to have built in native relaying? I'm assuming leaving it open allows for more creative innovation in the design space, for example, allowing external teams to integrate their relayer implementations. |
Beta Was this translation helpful? Give feedback.
-
|
I was just thinking through how a Hyperlane relayer integration with native interop could look like to allow message senders to pay a Hyperlane relayer to execute the message on the destination chain. However, I realized that the message identifier being unknown at dispatch time to make this quite challenging, which is why I wanted to ask about options here. Specifically, Hyperlane relayers need to be able to associated a payment event on the origin chain with the message that was paid for (so that i cannot be coerced to execute messages that it wasn't paid for). However, since native interop messages dont have an identifier when the event is emitted, no association can be done until the tx that emitted the event is included in a block. Thus the only way to do it in the same block IIUC, is to force the user funds to go through the wrapping contract (in Hyperlane's case the Mailbox), make the call to Is there a different way to associate events or state with a message on the origin chain to accommodate this use case that avoids the wrapping? |
Beta Was this translation helpful? Give feedback.
-
|
hey @nambrot !
would something like this make sense? |
Beta Was this translation helpful? Give feedback.
-
|
I couldn't find this in the specs, but what would be messageNonce in this case from step 2 and how to retrieve it? I.e. the crux of the problem seems that creating the relayId is difficult until after the message was included in the block? |
Beta Was this translation helpful? Give feedback.
-
|
you can find it on the specs here
not really, since you don't need to know the full identifier to "identify" a message, you can use the nonce feature of the |
Beta Was this translation helpful? Give feedback.
-
|
Ohh that's awesome, I somehow missed that. IMO that alleviates my issue as far as I can tell, thank you very much for the pointer |
Beta Was this translation helpful? Give feedback.
-
|
@skeletor-spaceman , figure i just continue our conversation here around an interface that doesn't introduce a wrapper. To maybe start with that as the starting design: Wrapper %%{ init: {
"theme": "neutral",
"themeVariables": {
"mainBkg": "#025AA1",
"textColor": "white",
"clusterBkg": "white"
},
"themeCSS": ".edgeLabel { color: black }",
"flowchart": {"useMaxWidth": "true" }
}}%%
flowchart TB
subgraph Optimism
User --"makeCallAndPayForRelaying"--> Wrapper
Wrapper --"sendMessage(target, data)"--> OL2toL2[L2ToL2CrossDomainMessenger]
Wrapper --"payForMessage(nonce)"--> OMailbox[Mailbox]
OMailbox --> IGP[InterchainGasPaymaster]
end
Relayer
IGP -."owned by".-> Relayer
Relayer --> Mailbox
subgraph Base
Mailbox --> ISM
ISM --> BL2toL2[L2ToL2CrossDomainMessenger]
BL2toL2 --"CALL(data)"--> Target
end
This wrapping contract can totally immutable fwiw, but understand that there might be folks who prefer to not insert a middleware contract for this for all their users. Hyperlane had a similar problem as IGP payments were previously a required 2nd call as well, and introduced hooks in v3. You can introduce that similarly here: %%{ init: {
"theme": "neutral",
"themeVariables": {
"mainBkg": "#025AA1",
"textColor": "white",
"clusterBkg": "white"
},
"themeCSS": ".edgeLabel { color: black }",
"flowchart": {"useMaxWidth": "true" }
}}%%
flowchart TB
subgraph Optimism
User --"sendMessageWithHook(target, data, Hook)"--> OL2toL2[L2ToL2CrossDomainMessenger]
OL2toL2 --"postDispatch(message)"--> Hook
Hook --"payForMessage(nonce)"--> OMailbox[Mailbox]
OMailbox --> IGP[InterchainGasPaymaster]
end
Relayer
IGP -."owned by".-> Relayer
Relayer --> Mailbox
subgraph Base
Mailbox --> ISM
ISM --> BL2toL2[L2ToL2CrossDomainMessenger]
BL2toL2 --"CALL(data)"--> Target
end
However, the disadvantage of this hook logic is that it would have to permeate through all the call sites so that users who lets say use %%{ init: {
"theme": "neutral",
"themeVariables": {
"mainBkg": "#025AA1",
"textColor": "white",
"clusterBkg": "white"
},
"themeCSS": ".edgeLabel { color: black }",
"flowchart": {"useMaxWidth": "true" }
}}%%
flowchart TB
subgraph Optimism
User --"sendErc20WithHook(to, amount, Hook)"--> SuperERC20
SuperERC20 --"sendMessageWithHook(target, data, Hook)"--> OL2toL2[L2ToL2CrossDomainMessenger]
OL2toL2 --"postDispatch(message)"--> Hook
Hook --"payForMessage(nonce)"--> OMailbox[Mailbox]
OMailbox --> IGP[InterchainGasPaymaster]
end
Relayer
IGP -."owned by".-> Relayer
Relayer --> Mailbox
subgraph Base
Mailbox --> ISM
ISM --> BL2toL2[L2ToL2CrossDomainMessenger]
BL2toL2 --"CALL(data)"--> DSuperERC20[SuperERC20]
DSuperERC20 --"tokens"--> DUser[User]
end
Given this, my recommendation is to still use a wrapping contract as I'm not sure we can afford to have the logic permeate through? |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the Liquidity Migration Spec, do I understand correctly that existing L1-bridged tokens on L2 will require a contract migration, i.e. DEX pools and everything have to be migrated as well? Let me know if this is the wrong venue to ask this question, but I wonder how it would play together with SuperOPxERC20? IIUC, they would be two different factories, but https://github.com/ethereum-optimism/optimism/pull/11479/files#diff-56cf869412631eac0a04a03f7d026596f64a1e00fcffa713bc770d67c6856c2fR88 seems to only allow for a single factory? |
Beta Was this translation helpful? Give feedback.
-
|
hey Nam! This is a very good question, Liq-migration allows fungibility between the legacy [MintableERC20] (1 or multiple) representations of an L1 erc20 (underlying) and it's unique superc20 representation. effectively allowing anyone to convert between all these options, without fees and without limits. MintableERC20 <> MintableERC20 <> Superc20
This is correct, and it has to do with 2 things:
|
Beta Was this translation helpful? Give feedback.
-
|
I don't quite follow point 1 if you could expand on that. And then on a different note, How come the above PR didn't need to modify L1StandardBridge? I.e. once a user has moved to SuperXERC20 token, how do they withdraw to L1 (as presumably the collateral remains on the existing L1StandardBridge, which only knows about L2StandardBridge? |
Beta Was this translation helpful? Give feedback.
-
|
We'll work on a document to clearly explain point 1. I'll share it here soonTM
quick note, there is no but to anwser the q', it's super easy, they convert back from the superc20 to the legacy-mintableERC20, and withdraw to L1 using the legacy-mintableERC20. is this clear? |
Beta Was this translation helpful? Give feedback.
-
|
Gotcha, so basically existing bridged tokens will always go via the legacy-mintableERC20, even if the migration is successful and most apps use the |
Beta Was this translation helpful? Give feedback.
-
|
exactly! |
Beta Was this translation helpful? Give feedback.
-
|
Greetings from Flayer Labs We have been working on an initiative to move L1 NFTs to Optimistic L2s using the Superchain bridge. The top level goal is to move as much NFT trade volume from ETH (which commands ~82% of trade volume) over to Superchain rollups. We will be looking to bridge ~$10M of Flayer treasury assets (~80 cryptopunks, ~120 miladys, ~70 remilios among others) and we are aiming to bring ~$150M more through a community incentives program. In order for us to achieve this today + make this viable we have had to add a wrapper to the Superchain bridge which achieves these three things:
We consider the first two functionalities are crucial for success of the overall outcome. Please find the current version of the wrapper (a public good open source set of contracts) here: https://github.com/flayerlabs/moongate *these are currently under audit with Omniscia and Sherlock We caught up with Binji who mentioned this aligned closely with Optimism’s overall vision. Our ideal scenario is that this functionality exists natively within the Superchain bridge - so a user journey is completely homogenised for both fungible and non fungible tokens. The wrapper is a little suboptimal as it kind of moves the NFT community away from the pure Superchain bridge and requires them to use a wrapped version - which is likely going to create some user confusion and debt for all parties. Where would love some feedback on:
Looking forward to your feedback <3. Also shout out to Owen(sudoswap), Apoorv(flayer), Twade(flayer) on the build <3 |
Beta Was this translation helpful? Give feedback.
-
|
hi @tynes (reposting my q from twitter for tracking): hi you mentioned an idea about how we can scale up chains on demand to load balance as tx volume spikes up; do you know if the opposite is possible (scaling chains back down as tx volume settles down)? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This is meant to act as an open discussion board for native OP Stack interoperability. This includes both the protocol layer message passing as well as the Superchain ERC20 token specification. Over time we will aggregate common questions and answers into the spec documents to scale knowledge about the OP Stack.
Media
FAQ
Is it a requirement that both chains are on each others dependency set?
It is not a requirement that chains are in each others dependency set. It is permissionless to define a dependency on a chain, so chain operators will be able to choose which chains their chains depend on. Optimism Governance is the arbiter of the dependency set of OP Mainnet.
New chains can add existing chains to their dependency set without their permission. This is because the nature of defining a dependency is one way. It is impossible for a chain to know of all of the chains that depend on it.
How will fault proofs work?
Read this early design doc
What additional infra do chain operators need to run in order to be part of the interoperable set?
The
superchain-backendmicroservice will be a requirement for running an OP Stack chain that has interop enabled. This service is responsible for validating all cross chain messages and will need to have an RPC configured for each chain in the dependency set. Over time, we would like to remove the requirement of configuring this service with RPCs and instead rely on the P2P network and cryptographic schemes for validating cross chain messages.How can the latency be so low (<2 seconds)?
Cross chain message can be optimistically accepted. The fork choice rule enforces eventual consistency, meaning that if an invalid cross chain message is accepted, it will be reorganized out eventually. The fault proof guarantees that all of the cross chain messages are accounted for from the perspective of handling withdrawals through the bridge to L1.
What is the latency/security tradeoff?
If a sequencer does not want to trust another sequencer at all, they can choose to only accept executing messages where the initiating message has been finalized with L1 levels of security. This demonstrates the difference in latency vs speed. The L2 data must be submitted to L1 and then the L1 block containing the transaction with the L2 data must be finalized. It takes about 15 minutes for an L1 block to finalize and higher throughput OP Stack chains like Base and OP Mainnet submit a batch about every 5 minutes. This means that it could take about 20 minutes for an L2 transaction to be considered final and be able to be trustlessly consumed by another chain. At lower latencies, the sequencer accepting the executing message takes on some amount of equivocation risk. It could be possible to build a bonding system to add economic security to prevent equivocation but that is not in the scope of the first release.
See this dune dashboard to see how often OP Stack chains submit batches.
What is stopping a sequencer from censoring a cross chain message?
There is nothing stopping a sequencer from censoring a transaction when it is sent directly to the sequencer. This does not mean the network has no censorship resistance, users can always send a deposit transaction for censorship resistance as strong as L1 guarantees. The tradeoff here is the latency, instead of being confirmed in ~2 seconds, the transaction can be confirmed at the rate of L1 block production. It may be possible to adopt something like EIP-7547 in the future to enable low latency censorship resistance.
Are callback style transactions possible?
If two blocks are being built at the same time with shared knowledge of their contents, it is possible to build blocks where a transaction calls to another chain, does compute and then a transaction calls back with the results. This requires no protocol level changes, it just requires more sophisticated block builder infrastructure.
What is stopping a shared sequencer from including just the executing message and not the initiating message?
The protocol enforces the fact that all executing messages are valid. It does this by reorganizing out executing messages that have invalid initiating messages. Running software that does not enforce this would be non-standard behavior and would leave yourself at risk of accepting an invalid executing message and therefore running on a forked chain.
What is the trust/verification model? Do Sequencers that opt into this interop system have to trust each other fully?
Sequencers only have to trust each other if they are accepting executing messages where the initiating message is unsafe. This is because the sequencer's ability to equivocate on unsafe data, ie batch submit something different than what they gossip over the p2p network. Once data is submitted to L1, it is considered final relative to the L2 and therefore there is no longer an equivocation risk.
Is interop different between chains with non fungible blockspace?
Chains that have non fungible blockspace are chains that have different features - it could be that they use Plasma for data availability, a custom gas paying token or have a large execution gas limit. As long as the chain can be fault proven, it can work with native interoperability. At the application layer, it is important for chains to have legibility into the type of chain that the message originated from. This ensures that applications do not accept messages from chains they consider not secure enough. See #121 for additional thoughts.
When it comes to chains that have different gas limits that are interoperable, it creates a set of transactions that can execute on one chain but not the other. This happens when the transaction consumes more than the gas limit of the smaller chain but less than of the bigger chain. At 2024 usages levels, these sorts of transactions are very rare. In the future it may be the case that these transactions become more common, it will be up to the chain operators to ensure quality of service for their users.
Beta Was this translation helpful? Give feedback.
All reactions