Data persistence in core & access from Scilla contracts


#1

Background

EVM based smart contracts model their data persistence like akin to in-memory variables within the contract, which is OK for simple applications, but makes it difficult (although not impossible) to model more complex applications.

Since Zilliqa has its own smart contract platform, I see an opportunity to rethink this assumption that we may have been inherited from the thinking around Ethereum/ EVM.

Ideas

In order to be enable developers to build more complex smart contracts, and therefore distributed applications, on top of it. Specifically, I would like to have the ability to do create, read, update, and delete operations on the data, natively within smart contracts.

By natively, I mean:

  1. The data is stored “on chain”, that is within the Zilliqa blockchain itself, not on an external system such as IPFS or another blockchain.
  2. Database read & write operations using Scilla primitives, perhaps following or adapting an existing standard like SQL’99.

Rationale

  • Developing on EVM limits the types of applications that can be built due to storage limits
  • Current solutions involve storing data off-chain, and thus become difficult for smart contracts to interact with
    • Either, the data is stored in such a way that only the front end application interacts with it directly, e.g. OrbitDB
    • Or, the smart contract interacts with the data through Oracles, e.g. Bluzelle
    • Or, some hybrid solution by means of syncing events emitted by the smart contract as the data to be queried
  • The current solutions available are all far from ideal, and hamper the ability to build a “true” distributed application when these types of data are needed
  • Since Ethereum has a much lower transactions rate, this limitation has been secondary. However, with Zilliqa, which has a much higher transaction processing rate, it would actually be possible to build applications whose smart contracts that respond as fast as a centralised web server, and thus this limitation is likely to come into the forefront as more distributed applications are developed on top of it.

Challenges

Apart from the direct implementation challenge, I foresee a secondary one, which is the design of the crypto-economic incentives for the disk storage and query computation on behalf of those running the nodes. This has been already thought of in the context of “variables” within smart contracts; however with larger and more complex data types and query execution methods, this would need to be thought through once more.