List view
A functional testnet needs the ability to run multiple nodes to demonstrate a functional (albeit not production ready) chain. Overview: * Ensure p2p setup and determinism for 4-node network * Allow for custom hooks (twasm style messages)
Overdue by 1 year(s)•Due by November 6, 2024•0/5 issues closedMake registry for contracts and interfaces to allow easy service discovery. This is not a "naming service" as much as a service for programs to bootstrap. Can be used to find the staking contract, list current available wasi services, possible account abstraction modules (and multiple versions), etc. It should also list common interfaces (like cw20, dao ones) and link to modules that support those. This will likely require some on-chain validation of the code behind contracts, but definitely their JSON Schema / ABI to provide discovery and indexing of this
No due dateCreate a system for off-chain workers to run WASI containers. All tooling needed. This is a placeholder for an idea that needs development
No due dateMake lay3r a proper L2 with AVS. Jake will need to define this milestone much better
No due dateEVM [revm ?](https://github.com/bluealloy/revm) embedded in lay3r, allowing clients to call either EVM or CosmWasm contracts. Also allow CosmWasm contracts to call EVM contracts (using RLP) and EVM contracts to call CosmWasm contracts (also using RLP). MetaMask should be able to execute both EVM and CosmWasm contracts Keplr, et al, should be able to call CosmWasm contracts. Maybe we figure out EVM support there?
No due dateThe goal is that MetaMask and ethers.js should be able to call into the Lay3r testnet like it was a EVM compatible layer 2. At least for a subset of the functionality we support. The first step is just standard tokens and accounts: * Query account (translate between lay3r bech32 and eth hex address... or always use eth hex style?) * Query token balance * Send native tokens The second step is to create special bindings for CosmWasm contracts to allow them to export ABI descriptions and parse RLP encoded calls as if they were solidity contracts. When contracts are set like that, we should: * Pass client queries to the contracts and properly decode data/events * Handle ethereum encoded contract calls properly * No need to handle instatiate ethereum code... this just calls cosmwasm contracts as if they were ethereum ones
No due dateAdd more power to contract scripting. These are special entry points we can support. Add more ideas here, for now it is: * Account abstraction (let a contract control account authorization) * Fee market (contract to check if sufficient gas is paid for the transaction)
No due dateUse ibc-rs as contracts and add any routing / registry to lay3r as needed. This should allow custom contracts to add client or connection logic as well as app logic. It must include a working implementation for ics20 (which needs privileged mint token permissions). Test it with ics20 transfers to a normal cosmos sdk testnet using standard relayers. Document which relayers work and what configuration is needed.
No due dateWe need to add a number of entry points into the system for "privileged contracts" which can control tendermint stake, minting, gov voting, etc. This can be modelled on the tgrade design to start and then extended/modified. These entry points should allow: * Staking tokens to adjust validator weight (dPOS) * Gov voting (token stakers, delegate vote to validator or anyone?) to do "sudo", "pin", etc * Custom genesis file setup (defined by contracts) so we can configure these well * Include wasm files in genesis setup We should integrate dao dao tooling and any needed adaptors. The bootstrap phase is important, so the genesis file should be able to configure an initial state with staked validators. We can start development with some admin account that deploys when live, but the milestone needs proper genesis launch possibility
No due date•0/3 issues closedMake sure we can run a network, that plays well with existing CosmWasm (and Cosmos) tooling from the existing ecosystem. We should make a lot of issues for this, but some key points: * Full client compatibility (legacy amino for Keplr, test abstract client queries) * Gentle error handling, not panic, on unsupported queries * Persistent storage (jellyfish?) for easy restart * Deploy WYND or DAO DAO on it and serve the web app to show compatibility * Ensure some Cosmos block explorer works with this (eg ping.pub)
No due date•7/7 issues closed* Rename all packages and documentation for the new name * Replace image and description in README * Transfer repo to new org
No due date•1/1 issues closed