Comments (16)
As IBC deals with message passing between blockchains with their own ordering mechanisms, I don't think it will be very useful in constructing the right interface between the optimistic rollup state machine and LazyLedger - ABCI sounds closer to the right starting point there - but IBC might be helpful as a standard for communication between multiple rolled-up chains, which presumably will be executing asynchronously from each other (so IBC's asynchronous model fits) - the client/connection/channel abstraction set could be used mostly unmodified, but internally the LazyLedger chain would implement special clients which can check cross-chain packets directly once the relevant blocks have been ordered by LazyLedger, this should be pretty efficient.
from celestia-core.
from celestia-core.
I would love to see an experiment of optimistic rollup of general cosmwasm contracts.
We approach 1.0 shortly, and that would be a good place to start experimenting, as no more versioning issues.
One issue is we allow callbacks to native sdk code, in particular staking and bank. That can be mocked out for a secure runtime, but there is an issue of the sdk integration to differentiate from pure contracts. Also the auth and fee processing takes place in native code
from celestia-core.
A few remarks:
It seems like this can be done purely on the Cosmos SDK side, by appending intermediate state roots to transactions.
I don't think this works. E.g. looking at https://docs.cosmos.network/master/basics/tx-lifecycle.html it does not seem a viable approach as the Tx are not meant to be modified after e.g. CheckTx. (@marbar3778 can you confirm this?).
Also, I feel like if this gets abstracted a bit to sth like, "the interaction between tendermint & the cosmos sdk need a way to add additional (tx related) data to the Txs", this could be very beneficial for the sdk and tendermint independent from ORUs and intermediate state roots. That is why issues like the pre-process one exist (cc @ValarDragon).
Furthermore, we would need to ensure that there is only one commitment in the block header that commits to state.
his may require removing other state-related commitments such as validator set etc (which we wouldn't need for a chain that doesn't have its own consensus anyway). This may require Tendermint/ABCI client modification.
Regarding state, the app hash is the only commitment to the (full) state. I think the SDK itself does not rely much on particular fields in the block header as tendermint does (e.g. the validator roots are required for tendermint and the tendermint light client to function properly as tendermint does not understand the notion of the abci app's state).
It sounds like for the ORU-based "abci-client" there are more substantial changes necessary anyways (like stripping out the consensus). Hence, if we change the block header like suggested, it isn't really a change to tendermint we'd like to see upstreamed but this more of change that would live in a fork of tendermint or the build from scratch "abci-client" that serves the same purpose (I like the names Optimint or Lazymint BTW). We'd have to make it easy for devs using the SDK with the modified abci-client to track the validator sets in the single state commitments (if they are necessary at all).
Question: is ABCI compatible with the use case of requiring intermediate state roots to be added to transactions after the user has submitted them: presumably after CheckTx passes, the intermediate state root can be appended to the transaction before DeliverTx?
See above. Using vanilla tendermint, I doubt that is possible. If you replace tendermint with "lazymint" (but rely on ABCI), you'd still need a way to get back these intermediate state roots into the block. But if we use our own abci-client, well then we can also do a slightly cleaner separation and have a dedicated field in the block for intermediate state roots. Regarding ABCI: it does not support that directly either but if we are modifying/implementing the underlying abci-client, we can probably sneak the intermediate state roots into the replies of ResponseCheckTx
or maybe ResponseDeliverTx
and make lazymint write them into the field. A cleaner way would be above mentioned pre-process approach.
Regarding the two options I don't have a good intuition yet which would be easier. But a few notes:
Modify Tendermint to replace BFT with aggregator(s).
It is possible to replace the consensus reactor:
https://github.com/lazyledger/lazyledger-core/blob/7b84a4c74317453c6fd4192b1b82619328b1b97c/node/node.go#L131-L154
There is an ongoing effort to make tendermint usable in different "modes" where only certain reactors are turned on. This
work could give a rough idea how to approach this. More info:
- https://github.com/tendermint/tendermint/blob/master/docs/architecture/adr-052-tendermint-mode.md
- tendermint/tendermint#2237
- tendermint/tendermint#5212
Create own our ABCI client (we could called it Optimint or Lazymint) that is based on aggregator(s) rather than BFT consensus.
Yes, that could certainly be much cleaner. On the other hand this might take much longer too (peer-to-peer network stack, mempool, storage etc. are already ready to be used in tendermint).
In order to decide which approach to take, I'd propose to describe the requirements of "lazymint" in more detail. It might turn out that we'd better off to start with a fork of tendermint and disable the reactors we don't need. Or it might turn out out that the differences still outweigh the similarities and we are better off by starting from scratch (we might still able to use parts of tendermint as libraries to get started).
from celestia-core.
Some other ideas.
ABCI applications need essential a fraud proof mode where they get an intermediate state, a TX and then compute the next state root.
You also need a more that lets you compute replay a block while computing the intermediate root.
There also needs to be some kind of paradigm for hot loading code for fraud proofs via container? Gvisor? FirecrackerVMs?
from celestia-core.
I'm not sure why we would need to hotload code via a container as @zmanian mentioned 🤔
It seems to me the problem of connecting different chains with each other (dynamically and without much or any coordination) came up already in the context of Dynamic IBC by the agoric team. Here is a post on that project by @dtribble: https://medium.com/agoric/the-road-to-dynamic-ibc-4a43bc964bca
Also related in this context is CosmWasm by @ethanfrey. Above mentioned problem & approach partly motivated this proposal for the Cosmos Hub to integrate CosmWasm.
from celestia-core.
If we restrict the rollup to a subset of cosmwasm contracts that only interact with the bank module, this should be just as a complete vm as the ethereum vm (which handles sending native tokens and checking balances).
Since we allow callbacks into custom blockchain code, full cosmwasm support would be a least as hard as generic sdk support. We could also not include ibc interactions in the rollup. But, I think a limited subset could be considered achievable, and that limited subset would actually be useful for many defi applications.
from celestia-core.
Create own our ABCI client (we could called it Optimint or Lazymint) that is based on aggregator(s) rather than BFT consensus.
Linking to https://github.com/celestiaorg/optimint which took this approach
from celestia-core.
Can you elaborate on why code would need to be hot loaded? The code for state transitions should be the same code defined by the app.
from celestia-core.
Any nodes that need to witness/ validate the fraudulent state transition.
from celestia-core.
They should have the code (i.e. state machine) for the Cosmos app, and then they could validate the state transition fraud proof by loading an instance of the app (state machine) that uses a database backend the contains the state of the app at the point of the contested state transition. This state is provided by the fraud prover, in the form of state tree Merkle proofs. I don't think any fancy VM technology would be needed for this.
from celestia-core.
I look forward to be proven wrong!
from celestia-core.
They should have the code (i.e. state machine) for the Cosmos app, and then they could validate the state transition fraud proof by loading an instance of the app (state machine) that uses a database backend the contains the state of the app at the point of the contested state transition. This state is provided by the fraud prover, in the form of state tree Merkle proofs. I don't think any fancy VM technology would be needed for this.
Could you explain this a bit more? As I understand it, you're saying that the L1 should have the code for the L2 state machine hardcoded, and not expressed in some VM language. This doesn't seem like it should be true to me, unless the L1 only has to verify a known subset of the L2 state machines code or only supports L2's that use the hardcoded state machine.
I do think hardcoding the lazy-ledger state machine into the L1 does make sense if its using it for data availability proofs. If this is whats happening maybe there is terminology confusion. Perhaps phrasing as the L1 hardcodes a "fixed ORU", and VM-based L1s support "arbitrary ORUs" may mitigate the confusion?
from celestia-core.
My sense is that the CosmWasm isn't necessarily a good fit here because it isn't designed to be an entire state machine.
CosmWasm is designed to extend the capabilities the CosmosSDK state machine rather be an entire state machine unto itself.
from celestia-core.
this issue could still be relevant for rollkit, but depending on #84 (comment) we might not need this issue as well
from celestia-core.
from celestia-core.
Related Issues (20)
- Allow the user to request a proof of the tx's inclusion if it has been committed
- RequestPrepareProposal has unclear comments HOT 1
- Remove outdated TODO HOT 1
- Add ability to subscribe to block data via grpc HOT 2
- Add ability to request a block via its hash HOT 1
- Port not blocking on receives work from upstream HOT 1
- Expand `TxInfo` to save the resulting code of the transaction
- Proposal: Use CometBFT protos
- Investigate malformed data in JSONL traced files HOT 2
- Compare CAT vs V1 distribution times
- Update openapi specs with TxStatus changes
- Provide more information to users in regards to pricing
- Don't vote until the local time is past the start time HOT 1
- Use the start time as the time in the votes HOT 1
- Try a high level sanity test that doesn't rely on using `tc` for artificial latency HOT 1
- Wait to vote until the end of the proposal period HOT 1
- Port performance changes from upstream
- Sanity benchmark tcp with latency and many peers HOT 1
- Ability to spin up many geographically distributed nodes
- Add IPv6 Support for Application Protocol HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from celestia-core.