Database characteristics of a Lisk blockchain

Hey folks :partying_face:,

Earlier today I asked myself a question about storing data on lisk-sdk blockchain. After reading through many resources and also the NFT tutorial I am still not sure about my assumptions.

Question: How should blockchain state be persisted which is unrelated to user accounts? And does every new permanently added & searchable/queryable kind of data need to be added to the genesis block?

My first resource was again Nazar’s talk. At minute 20:30 he talks about that the account state of the genesis block. Once one modifies the account state for an application and introduces another account state, this state needs to be included in the genesis block configuration. That’s why I thought any none-temporary chain state also needs to be included there.

The NFT tutorial mentions “state store” a lot - but I understood this as a mechanism to temporarily story chain state during the processing of all transactions included in a block.

But then there generally are the concepts of transaction and asset - which are purposefully separated - and I am not 100% sure yet why. Is the reason there that all assets also are stored for ever on the blockchain?

Thank you very much in advance! :v:

1 Like

You have an account state which is made up of all accountSchemas from all the modules.

Every transactionAsset has also a schema which defines the assets (arguments) a transaction allows/needs.

When a transaction is included in a block, these are stored forever (after finality of course). The transactions could modify the accountSchema from it’s own module; eg. TransferTransaction can change the balance in it’s token module.

Also you could modify accountSchema’s through reducers, eg you buy an nft you could use the debit and credit reducer of the token module to manipulate the token balance from a custom module.

You can additionally use the chain store to store extra data, eg. an NFT, you can store the nft something like nftstore:{nft_id}:{encoded_nft_data} and can access it later, to define the owner, you can add this nft id in the account state of your module.

The part where you talk about the genesis block, when you make a custom module with an account schema. You need to have the default account state in the genesis accounts. Eg. nft: { ownedNfts: [] } to start an account with an empty array of ownedNfts.

Hope answers your questions.

Thank you @Moosty, I could definitely already take a couple of things from your text.

After thinking even more about it, I think I can better explain what I want to wrap my head around:

I see the use case of storing some kind of blockchain config on-chain which can be modified / changed by modules. And all modules/plugins have access to this configuration to use it for their logic.

A simple example could be that a real-estate-management blockchain application has a set of possible types of real estates types = [apartment building, parking lot, simple house]. A user account of the blockchain - maybe a “founder” account - could then have special permission to add another type to the configuration, e.g. skyscraper.

There of course are modules & transactions which assign real estates ownership to user accounts and could then create assets with this new estate type.

Does my example get us anywhere …? :grimacing:

You can use the chain state store for that, like an NFT you could also store one or more rows config schema’s in there.

You could pick your key whatever you want (if it doesn’t conflict with the native used keys) eg. chainconfig:anotherSubKey could be used it could be one big store in with one key. But you could add as many as you want. You can then update them with transactions.

… But what should one do? What are typical use cases for adding new data to the genesis block (except additions to account schema) and when to the state store? Every time the docs are mentioning stateStore/chainState they state which holds temporary state …

To also not leave this thread open ended I answer to myself, today a bit more educated:

Adding other data (=key-val pairs) to the genesisBlock other than what is there by default is not supported for now.