Integrate cosmwasm module into laconicd #25

New Issue

i-norden · 2022-08-31T16:43:41Z

i-norden commented

2022-08-31 16:43:41 +00:00

From Ashwin: Integrate the latest cosmwasm module into chiba-clonk, enabling us to run cosmwasm contracts on chain.

~~Refactor cosmwasm stack onto SDK+SMT~~
Update laconicd to load the cosmwasm module into the BaseApp
Deploy a CosmWASM contract and run it in the testnet

From Ashwin: Integrate the latest cosmwasm module into chiba-clonk, enabling us to run cosmwasm contracts on chain. - [x] <s>Refactor cosmwasm stack onto SDK+SMT</s> - [ ] Update laconicd to load the cosmwasm module into the BaseApp - [ ] Deploy a CosmWASM contract and run it in the testnet

i-norden commented

2022-11-17 15:05:29 +00:00

To be able to run small pieces of warm to run.

Off chain someone runs watcher, claims state root of watcher at certain height.

If someone wants to contest, they send a tx to laconic claiming an operation produced the wrong result.

On chain, we execute a small portion of the watcher execution graph (within the cosmwasm execution environment) to see that the state root produced is not as expected.

For fraud proofs in the responder group, at the L3.

To be able to run small pieces of warm to run. Off chain someone runs watcher, claims state root of watcher at certain height. If someone wants to contest, they send a tx to laconic claiming an operation produced the wrong result. On chain, we execute a small portion of the watcher execution graph (within the cosmwasm execution environment) to see that the state root produced is not as expected. For fraud proofs in the responder group, at the L3.

i-norden commented

2022-11-29 14:15:19 +00:00

TODO:

Port wasmd x/ module here, fix any dependency related breaks #92
Set so that no accounts are authorized to create
Create new eval keeper method that accepts WASM bytes, executes them, returns result without storing code or result in state
Provided to this method is not the WASM itself, but a reference to registry record containing the registered WASM (must register before evaluating)
If we can cleanly cut out the unused code paths we should, but if it disrupts the remaining code such that rebasing on future releases is complicated we may want to leave them as vestigial pieces

Notes:
Figure out how we manage/guarantee access to the state necessary for the execution (parameters, but much more data than possibly can be provided as call parameters)

Provide content IDs (e.g. set of state roots) for the state necessary, which can be fetched from IPFS as needed.
Each member has some subset of the various chain's IPFS blockstores, we need some aggregated view on top of all of the blockstores so that we can perform any of the state transitions necessary for watcher evaluation.
Members could form a private IPFS swarm

TODO: - [ ] Port wasmd x/ module here, fix any dependency related breaks #92 - [ ] Set so that no accounts are authorized to `create` - [ ] Create new `eval` keeper method that accepts WASM bytes, executes them, returns result without storing code or result in state - [ ] Provided to this method is not the WASM itself, but a reference to registry record containing the registered WASM (must register before evaluating) - [ ] If we can cleanly cut out the unused code paths we should, but if it disrupts the remaining code such that rebasing on future releases is complicated we may want to leave them as vestigial pieces Notes: Figure out how we manage/guarantee access to the state necessary for the execution (parameters, but much more data than possibly can be provided as call parameters) * Provide content IDs (e.g. set of state roots) for the state necessary, which can be fetched from IPFS as needed. * Each member has some subset of the various chain's IPFS blockstores, we need some aggregated view on top of all of the blockstores so that we can perform any of the state transitions necessary for watcher evaluation. * Members could form a private IPFS swarm

AFDudley commented

2023-01-30 04:19:59 +00:00

Should this issue be closed?