1) Layer 2 consists of shards that communicate, yes. A shard is typically associated with one underlying blockchain, but we have extensions to this in the roadmap where a shard can be can read data that is written across multiple blockchains to improve availability. But for now, we can assume one shard is associated with one blockchain.
2) The shards take some limited data from other shards, called jump transactions (sometimes we also call it sibling data), and data from the underlying blockchain. Which shards this data can come from is relatively fixed (this is based on the delay graph). A requirement for a blockchain to work with Coinweb is that its consensus protocol requires and checks a timestamp for its blocks, and that no block can be accepted in the consensus system if its timestamp is too far off from the current timestamp.
The shards can read data from the underlying blockchains. For example, on Ethereum, they can read the event logs.
We say that they are listening to the blockchain, i.e. they have an interface to the L1 block. I typically don't use the term "shard" when talking about the L1 blockchain, but rather when talking about the Coinweb shard that reads the blockchain.
3). Atomically means all or nothing. When I say that an L1 transaction atomically changes both L1 and the coinweb shard on top of that L1, it simply means that there is no situation where it can only affect the smart contract at L1, but not the coinweb smart contract.
A different interoperability system could work like this: You post a transaction to L1, and someone posts a proof of that transaction to another blockchain, to a smart contract that does some sort of verification (native bridges do this for example, actually most bridges). In such a system at least two things makes it not atomic. First, the proof of the transaction can simply not be posted to the other blockchain. Secondly, the transaction can be posted, but be censored by the miners on the other blockchains. With the rise in MEV, it is not unthinkable anymore for an actor to censor transactions across most if not all, validators on a blockchain.
In Coinweb, this is atomic. The L2 shard is defined based on the data at L1 (plus jump transactions), and there is no consensus that allows censorship to happen. There are no arbitrary decisions that can break the atomic property.
For an L1 transaction that affects the Coinweb L2 shard, it is atomic and immediate. However, for jump transactions, we often use another word, "consistent" as opposed to atomic even though they both mean "all or nothing". A jump transaction posted into L1 on blockchain A will be part of the Coinweb L2 shard immediately, but will then wait for a delay before affecting the target Coinweb L2 shard.
There is no case where the jump transaction can only be on the source shard, but not appear on the target shard. The reason why this is so is because there is no consensus involved, and thus nothing "to vote over" or decide. When there is nothing to decide, there is not any possibility to censor information and cause failure of the protocol.
The delay is on purpose, and this is why. Blockchains typically have what is called eventual consistency. This means that while reorganizations are unlikely events, they do happen. Without any delays for information propagation, it would be possible to force a reorganization in an L1 blockchain that would cause a reorganization of the Coinweb L2 shard that is defined to read that L1 blockchain.
If the shard contained jump transactions, the neighbour shards would also be reorganized, and the reorganizations would ripple through the whole network of Coinweb shards.
This is actually not that bad, but we don't want this for a couple of reasons.
First, we don't want to recompute data too much. There are ways to optimize to avoid recomputation, so this is likely not the biggest problem.
More importantly, we don't want users of a Coinweb shard to experience any more reorganizations than what you expect from the L1 shard. That is, if you are using Coinweb on top of Bitcoin which is an exceptionally strong blockchain, we don't want Coinweb to introduce any extra reorganizations for the "Bitcoin Coinweb shard" just because it happens to have a noisy neighbour in the delay graph. I think this just creates confusion and a bad user experience.
So how do we decide on the delay? What we typically want is to make the delay X so that if we look at the block that has age >X, the probability of a reorganization to be so large that it reaches the block, is insignificant compared to the probability of reorganization of the first block of the target blockchain.
Thus when the target shard now includes jump transactions from the source shard that has aged X time, then this will not affect the probability of reorganizations of the shard.
Regardless of the delays in the delay graph though, the Coinweb system itself is eventually consistent and will reorganize based on reorganizations coming from L1 or through the delay network. The delays are there to create famiilar semantics for the Coinweb shards, but they don't affect the correctness of Coinweb. A black swan extreme reorganization that is longer than the delay in the delay graph is handled fine by Coinweb, but like most reorganizations, is an unwanted experience for users. It will spill over from one Coinweb shard to its neighbours, and that's unwanted, but the system will handle it just fine.
No comments:
Post a Comment