Boba Network
Replies: 3 comments 4 replies
-
|
The term 'decentralization' is important, but easy to turn nebulous as it's somewhat 'buzzy'. So, I guess my first question would be, "what specifically are we trying to decentralize"? An answer of 'everything' might be valid, but also not very helpful. So, it's probably worth discussing more concretely not only which components we see as in most urgent need of decentralization, but also what sort of decentralization. For instance, you mention PBFT; it's a fine and well understood protocol but practically suitable only for a relatively static low (but consistent) cardinality of nodes. So, if we were interested in having 4 permissioned entities each participating in the sequencing, PBFT might be a fine option, but would that truly satisfy the goal? To address the issue of maintaining forks of all of these components. Certainly, it's not feasible. But, at the same time, hopefully the modular nature of these components means true forks are not really required. For instance, we have not made any modifications to the golang op-node, and presumably (hopefully), we could pick up a rust version without any modifications as well. (So, no fork). Where things get a little trickier is with the actual Ethereum clients and the fraud proofs. If we want to have custom transaction processing for the fee token and or the hybrid compute, then we will need forks of clients. And, depending on the implementation of the fraud proofs, possibly forks of these. I know it's been discussed whether we could use account abstraction for the fee token bit, and whether we use something that's more application layer for the hybrid compute. Personally, I think it would make a great deal of sense to try to push both of these out of the Ethereum client and into the application space, because then we can eliminate maintenance of these forks. Though, there's a similar argument to be made that if Boba is a simple op-stack chain with no differentiation, why bother? |
Beta Was this translation helpful? Give feedback.
-
|
All great points Jason! A bit of structure or context so that everyone is on the same page: Once you remove upgradeability - you leave the protocols fate in the implementation of L2 operator(s), because sequencing and proposing is in the hands of the L2 clients (everything you've listed!). So in general having multiple implementations of the same specifications (I don't need to tell you that) is to have confidence in the codebase and that the network does not halt (until fix is rolled-out). An invalid state transition in a network that is completely built out of a single client would likely not even be detected! So I guess we established - yes we need multiple Ethereum execution clients that would support the decentralization of the network. On the other hand I want to mention Solana (I think) and Bitcoin that have a single client implementation. But Solana has not so very good uptime, and Bitcoin development has basically stopped. So how much decentralization do we want?
I guess the important bit here is that we cannot afford a lot of work because we plan to have other things to focus on.
I guess in general, the vision is that the L2 space would be big enough for it to make sense and capture some market. Forks with no differentiator to Optimism can actually strive https://l2beat.com/scaling/projects/base. I agree with your statement:
And to elaborate why I agree with your statement:
Because we cannot afford to do decentralisation any other way. |
Beta Was this translation helpful? Give feedback.
-
|
Hybrid Compute will require small changes to op-node (actually the op-geth library it uses) to recognize the new offchain transaction type. In general, hybrid compute does make decentralization more difficult. We only want the active sequencer node to be generating HTTP traffic to the offchain endpoints. At a 2s block time, it's possible for a transaction to be kicked out of one block and then to be included in a later block after its offchain response has been received. That wouldn't work well if block N+1 is generated by a different node than the one which generated block N. |
Beta Was this translation helpful? Give feedback.
-
|
@mmontour1306 Do you have any design document or similar around the new implementation of hybrid compute? I'd really like to understand the challenges and proposed solutions. I'd like to help think about if or how we could possibly transition this towards a more 'application space' solution as mentioned above. It's probably a little too big for this discussion, but maybe you or I could open an issue or another github discussion around this? |
Beta Was this translation helpful? Give feedback.
-
|
I don't have anything that's up to date, but I will put something together and share it with you (+ the rest of the team). |
Beta Was this translation helpful? Give feedback.
-
|
Taking in from Ino and Jason's discussion, I'll try to organize my thoughts around removing I think the bare minimum to theoretically make upgradeability go away is to have working fraud proofs (which you already mentioned). But practically, client diversity is definitely required. For now I'll just follow down the theoretical path to get through the first layer of decentralization. Fraud proofs, of course still doesn't remove centralization, because it still involves 'us'. Proposer: Sequencer: The various ways the centralized sequencer is a problem-
"can commit fraud" can be crossed out - since now everyone can challenge "Ordering of Txs" - is where I believe multiple sequencers could help a lot. A PBFT could be useful. But if there are passive sequencers or a consortium and slashing mech to discourage the primary sequencer from defaulting, I think single seq still works "central point of failure" - multiple sequencers are useful. An alternative with single sequencer is - if the seq disappears, a user could still submit the state batch transition themselves on L1 (as a proposer) and withdraw all assets from L2. "Point of Censorship" - similar to last point, force tx prevents the seq from having the ability to censor for a long time. Re - the point about grieving and convenience, yes - multiple sequencers are better. I think theoretically a single sequencer can preserve the ethos of decentralisation, practically although, client diversity is definitely required, I would argue particularly more for the proposers, replicas and cannon/validity proofs because it all converges to detecting and challenging. |
Beta Was this translation helpful? Give feedback.
-
|
https://twitter.com/sgoldfed/status/1699668423284772864?s=20 |
Beta Was this translation helpful? Give feedback.
-
I’ve been having some thoughts around decentralization.
To “decentralize”, we could utilize something like PBFT, maybe even try to simplify it and use what Jia is working on for leader election and make things interestingly unique.
The problem is that “good” decentralisation requires client diversification (op node is being written in Rust too!) + sequencers (erigon, geth, nethermind) that run Bedrock. And Cannon for fraud proofs (Optimism) and validity proofs (risc0) is working on. Commonly known as challenge games.
Now Boba have this thing Bedrock running and then we attach Anchorage (HC + erc20 fees) to it. At this point, we would be able to migrate all existing Boba rollups.
It seems to me that the consequence of this (Anchorage work) we need forks of the above, and maintain these forks too - if we want to leverage existing open source community work.
Seems to be very much not feasible.
Beta Was this translation helpful? Give feedback.
All reactions