3 ms·

Thanks for this explanation. Do you know anything of how Mina would handle things that need to exist in the public state of a blockchain, but which cannot be l

Thanks for this explanation. Do you know anything of how Mina would handle things that need to exist in the public state of a blockchain, but which cannot be learned from the 22KB proof—for instance, DeFi smart contracts? For something like a DeFi DEX to be useful, it's not enough to know that specific operation succeeded. It has to be possible for anyone to invoke the operation themselves, and that means that the state of the smart contract, and the contract's executable code, need to be publicly known.

baby 5y ago
These are called snapps in Mina, basically the state of a smart contract is nothing more special than the balance of an account, so you can store it on the blockchain in the same way. Now Mina is a succinct blockchain and zkp allows most data to be stored off-chain so I think the idea will be to limit heavily the amount of on-chain data.
- legutierr 5y ago
  I just get the feeling that "on-chain data" doesn't mean the same thing in Mina as it does with other blockchain systems. The 22kb is a ZKP and would not contain any contract logic or contract data, I think, so any contract data and logic would have to come from another source.
  - baby 5y ago
    The 22kb, which is more like 11kb I believe? is a proof of the state, you don’t get the balances of all accounts within the proof itself, that’s something you need to download separately.
milkey_mouse 5y ago
Each block contains a commitment to the state of the chain in the form of a Merkle tree. In that regard it's not that different from Bitcoin's MAST or Ethereum's (WIP) stateless clients. To prove something (say, an account balance) is in the block, one would need to know the data you're trying to prove as well as its Merkle path in that block's tree. > that means that the state of the smart contract, and the contract's executable code, need to be publicly known. Yes, they would need to be separately distributed somehow. But I think this is similar to how Ethereum contracts typically have their source code (and by extension ABI) uploaded to Etherscan, without which they'd be difficult to interact with. > Do you know anything of how Mina would handle things that need to exist in the public state of a blockchain, but which cannot be learned from the 22KB proof—for instance, DeFi smart contracts? A good rule of thumb is that Mina full nodes behave like other blockchains' light clients that just happen to sync quickly & trustlessly. I am not an expert on smart contracts, but I think in practice, a Mina DEX would probably work something like this: - You visit minaswap.io or whatever (or a copy on IPFS). The static page includes a copy of the contract's interface. - The page tries to call a hypothetical Mina browser extension running a full node in the background. If it's installed, it uses it; otherwise, it downloads & runs a Mina full node compiled to WASM as a "polyfill". - As the WASM node syncs & verifies the latest block's proof, it asks someone for the contract's current state and the Merkle path to it within the block. - Once the node has synced, it verifies the contract's data is actually in the Merkle tree using the given path. Now we know the interface & state of the contract and that's all we have to keep locally. Also: although block producers don't necessarily have to, provers always keep a copy of the current ledger state (see my above comment; sorry if my first comment was a bit misleading). This would include smart contracts' state (but not their code). If you run one of these nodes, it knows every contract's state, which should still be small compared to Ethereum as so much can be done off-chain.

baby 5y ago

These are called snapps in Mina, basically the state of a smart contract is nothing more special than the balance of an account, so you can store it on the blockchain in the same way. Now Mina is a succinct blockchain and zkp allows most data to be stored off-chain so I think the idea will be to limit heavily the amount of on-chain data.

legutierr 5y ago
I just get the feeling that "on-chain data" doesn't mean the same thing in Mina as it does with other blockchain systems. The 22kb is a ZKP and would not contain any contract logic or contract data, I think, so any contract data and logic would have to come from another source.
- baby 5y ago
  The 22kb, which is more like 11kb I believe? is a proof of the state, you don’t get the balances of all accounts within the proof itself, that’s something you need to download separately.

milkey_mouse 5y ago

Each block contains a commitment to the state of the chain in the form of a Merkle tree. In that regard it's not that different from Bitcoin's MAST or Ethereum's (WIP) stateless clients. To prove something (say, an account balance) is in the block, one would need to know the data you're trying to prove as well as its Merkle path in that block's tree. > that means that the state of the smart contract, and the contract's executable code, need to be publicly known. Yes, they would need to be separately distributed somehow. But I think this is similar to how Ethereum contracts typically have their source code (and by extension ABI) uploaded to Etherscan, without which they'd be difficult to interact with. > Do you know anything of how Mina would handle things that need to exist in the public state of a blockchain, but which cannot be learned from the 22KB proof—for instance, DeFi smart contracts? A good rule of thumb is that Mina full nodes behave like other blockchains' light clients that just happen to sync quickly & trustlessly. I am not an expert on smart contracts, but I think in practice, a Mina DEX would probably work something like this: - You visit minaswap.io or whatever (or a copy on IPFS). The static page includes a copy of the contract's interface. - The page tries to call a hypothetical Mina browser extension running a full node in the background. If it's installed, it uses it; otherwise, it downloads & runs a Mina full node compiled to WASM as a "polyfill". - As the WASM node syncs & verifies the latest block's proof, it asks someone for the contract's current state and the Merkle path to it within the block. - Once the node has synced, it verifies the contract's data is actually in the Merkle tree using the given path. Now we know the interface & state of the contract and that's all we have to keep locally. Also: although block producers don't necessarily have to, provers always keep a copy of the current ledger state (see my above comment; sorry if my first comment was a bit misleading). This would include smart contracts' state (but not their code). If you run one of these nodes, it knows every contract's state, which should still be small compared to Ethereum as so much can be done off-chain.