Can plutus contract store large data onchain alike to Ethereum's solidity?

We would like to implement plutus contract to peform the same function as our existing solidity contract , that is to store large merkle tree onchain. It seem we want to use Cardano as a database, that’s what we plan to do.

I’am doing research on the official site, have no conclusion yet.

Any advice or suggestion are welcome.


Cardano has small size limits for block data. What specifically are you trying to do while storing that data on-chain?

1 Like

My goal is to provide an serivce for other contract to call.

This service has the ability to store, update merkle tree as time move. The consumer of this serice receive the verify path and target hash by way of off-chain channel, then use the path to invoke Cardano contract(that is my service) to verify that input hash is correct.

Currently the requirement is that verification should be done on-chain, not off-chain.

1 Like

You’d do verification off-chain using on-chain data. Probably only store the top hash and then have the rest of the tree on IPFS. It’s hard to understand from your description though.

1 Like

Thanks for your reply. Sorry for poor description.

I know we can do verification off-chain, but this not the consumer side want.

It function is similar to sidechain. From the viewpoint of consumer, they expect to invoke my contract from their contract, so they can do something if pass verification. That is why I should do verify on-chain.

From the docs, I knew Cardano contract compose of on-chain and off-chain parts. From technical view, maybe my consumer can implement functionality inside off-chain code, not on-chain code, then I can choose to implement verification off-chain.

It sounds like what your trying to create is a general service contract for verifying changes to a piece of data. What’s unclear is the structure of this data and whether it all needs to be on-chain, or only parts of it. This is an issue since you can’t really provide a general solution for many different requirements with one contract.

Updating a merkle-patricia (MP) trie is NOT conducive to on-chain data or smart contracts in Cardano. Period.

Whatever SC you are porting from Ethereum needs to be re-imagined or re-factored entirely. Generally trie data structures are excellent for indexing known data. The MP “enhancement” as implemented by ETH storage layer adds verification via hashes and other integrity checks etc. These kinds of complex and error-prone algorithmic extensions placing the onus of dynamic validation onto the smart contract implementation is presumably why Plutus and Cardano smart contracts where designed to be deterministic and functional.

Back to the drawing board my friend, our preconceived notions are just that!

I admit that we should not put the method of thinking from ETH to Cardano. But the module/system I’m trying to implement do have relation to transactions on ETH-like chain,and need to hook up the Cardano and this ETH-like chain. Just like side-chain or layer two of ETH. That is why there is the need to store merkle tree on Cardano, maybe on-chain or off-chain.
If save large data on-chain is impossible, I had to found a work-around solution.
I’m learning Plutus now, but need to set a direction on how to design and implement this system ahead.

Maybe my requirement is due to our intuition that saving data on-chain will make the user trust our smart contract.

I would store the trie off-chain and use the hash in phase 1 validation. The idea with a deterministic system is validate first and only then execute. There should be no branches of control flow that can do this or maybe that depending on something mutable during runtime. The general idea with Plutus is if everything checked out and looks good in the off-chain portion then it should be guaranteed to succeed with a provable outcome on-chain.

Hello @brooze

There is a company that provides a EVM like sidechains that can run Solidity as well (if that’s what you want) on Cardano already. Did you try reaching out to:

My CIP for extended 721 metadata might prove to be somewhat relevant. The goal here is to store data onchain using references. This can be quite powerful and allow for certain data structures, combined with contract use could be quite interesting.

This is perfectly possible, see this post (1). The Merkle tree lib is already made as well (see post).

I think people misunderstood your question, you are not storing the data onchain, you are committing to it onchain via a hash (a low storage impact solution).