$75.78 K
4.11%
Website | cartesi.io |
---|---|
Docs | docs.cartesi.io/cartesi-rollups |
Explorer | cartesiscan.io |
Repository | github.com/cartesi/honeypot |
Social | @cartesiprojectDiscordcartesi.io/blog |
...
...
Currently the system permits invalid state roots. More details in project overview.
All of the data needed for proof construction is published on chain.
Users can exit funds at any time because contracts are not upgradeable.
In the event of a sequencer failure, users can force transactions to be included in the project’s chain by sending them to L1. There is no delay on this operation.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
Ultimately, Cartesi DApps will use interactive fraud proofs to enforce state correctness. This feature is currently in development and the Honeypot DApp permits invalid state roots. Since Honeypot is immutable, this feature will not be added to the DApp.
Funds can be stolen if an invalid state root is submitted to the system by the configured Authority (CRITICAL).
All executed transactions are submitted to an on chain smart contract. The execution of the rollup is based entirely on the submitted transactions, so anyone monitoring the contract can know the correct state of the rollup chain.
The Cartesi node software source code can be found here.
No compression is used.
The genesis state is derived from the Honeypot Cartesi Machine template, which can be found within the Honeypot server Docker image at /var/opt/cartesi/machine-snapshots/0_0
. Alternatively, it is possible to recreate it by following the build procedure outlined in the Honeypot GitHub Repository.
The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Because the state of the system is based on transactions submitted on-chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract directly.
The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. The process of block finalization usually takes several days to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.
Funds can be frozen if the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production (CRITICAL).
CartesiDApp instance for the Honeypot DApp, responsible for holding assets and allowing the DApp to interact with other smart contracts. This contract can store any token.
Contract that receives arbitrary blobs as inputs to Cartesi DApps.
Contract that allows anyone to perform transfers of ERC-20 tokens to Cartesi DApps.
Simple consensus model controlled by a single address, the owner.
Contract that stores claims for Cartesi DApps.
Contract storing bounty funds.