Research ICON Network

[quocle108]

Acceptance criteria

• [x] How ICON store Data
• [x] How ICON read/query Data
• [x] ICON transaction Limitation
• [x] ICON smart contract Limitation

[manh-vv]

make document for #3

[quocle108]

State Database:

In general, the state database is a key-value database, and can be accessed using VarDB, DictDB and ArrayDB classes.

VarDB can be used to store simple key-value state, and DictDB behaves more like Python dict. DictDB does not maintain order, whereas ArrayDB, which supports length and iterator, maintains order.

I’ve make some several tests on my computer and the result:

• Write/Read : it can write up to 20’000 indices per transaction.

Read/Query Data:

• The contract owner should write API to query state data.
• Other Dapps should read data through API which is provided by the contract owner. There is no way for other smart contract can access state data directly from the database.

ICON transaction:

• Time to include transaction to block: 2 seconds

• To ensure stable operation of the ICON network, it will have step limit(transaction fee). the maximum available amount of Step that can be used for a single transaction is limited to 2.5 billion Step. Initial setup: 1 ICX = 100,000,000 Step

• The maximum size of data is 512 KB.

ICON Smart Contract:

• We can easy to process with JSON data in SCORE. With this feature, we can decide to store state data as JSON or index data
• For every smart contract requested to deploy to the ICON mainnet, it needs to be passed the Audit Process. The audit process may take several days. (This is a centralized feature)

The difference compare with EOS:

• Users only pay the fee for a transaction. No need to maintain RAM/CPU/NET
• The state database can process data (read/write) better than EOS (20’000 indices per transaction). With EOS we read/write about 200 indices per transaction. (The test with my computer).
• The transaction will be limited by Steps (transaction fee) and data size. Transaction in EOS will be limited by CPU/NET
• The state database only supports primary index. EOS has secondary index
• The DApp owner should provide query APIs to read data from state database in ICON. There is no way to read state data directly from database. In EOS, The system provides a way to access state database through system API. It means the DApp owner no need to write the query API.
• Smart Contract can process JSON data simply
• Deploy smart contract need to be passed the Audit process
• There are no multiple signatures in a transaction. But you can define the multiple signature for a wallet (account). In EOS, you can define multiple-signatures for a transaction and an account
• There are no way to delegate permission/ custom permission on ICON. We can do it on EOS
• The transaction only executed from external. EOS has internal transaction (deferred transaction).

[quocle108]

@flowersinthesand @manh-vv Pls review this.

[flowersinthesand]

@quocle108 Thanks for your research. I have some questions.

In general, the state database is a key-value database, and can be accessed using VarDB, DictDB and ArrayDB classes.

What does mean we can access the state database through various databases? Is it similar that EOS' history-tools provide various database bridges?

There is no way for other smart contract can access state data directly from the database.

What database? smart contract tables that belong to other contract owner?

The state database can process data (read/write) better than EOS (20’000 indices per transaction). With EOS we read/write about 200 indices per transaction. (The test with my computer).

Is the index you mentioned the same a key-value pair or a column of some table?

To design an abstraction that works on both ICON and EOS, I think we need to drop sophisticated features of EOS like fine-grained access control and inline transactions which aren't supported in ICON and maybe others too so guess the final result would be a kind of ORM for blockchain which allows to read and push transactions with data to various blockchain softwares.

BTW can you write a table that lists supported data types by EOS and ICON with notes like maximum, minimum, exceptions, etc.? so that we can extract its common area to design the abstraction.

Data type	EOS	ICON
string	foo	bar
number	foo	bar
boolean	foo	bar
null	foo	bar
array	foo	bar
key-value pairs (hash, dictionary, etc.)	foo	bar
other type1	foo	bar
other type2	foo	bar

[quocle108]

What does mean we can access the state database through various databases? Is it similar that EOS' history-tools provide various database bridges?

VarDB, DictDB, and ArrayDB are the kind of data structure you can store to easily insert/remove/update your data.

• VarDB: store one value
• DictDB: it most likely un-order map
• ArrayDB: vector

What database? smart contract tables that belong to other contract owner?

Each blockchain has its database. Smart contract like a backend to insert/update/remove state data from the database.

Example: I have 2 contracts A, B

• In ICON, A can read data from B through B's API. Each smart contract has it's API to read data from database, external users read state data through A's API or B's API

• In EOS, A can read directly B's data from database. The system has the system API for the external users to get state data by get table api

Is the index you mentioned the same a key-value pair or a column of some table?

It's table's row in EOS

To design an abstraction that works on both ICON and EOS, I think we need to drop sophisticated features of EOS like fine-grained access control and inline transactions which aren't supported in ICON and maybe others too so guess the final result would be a kind of ORM for blockchain which allows to read and push transactions with data to various blockchain softwares.

It should be inline actions. and ICON also supports the inline action. Transaction can include multiples actions

[flowersinthesand]

BTW can you write a table that lists supported data types by EOS and ICON with notes like maximum, minimum, exceptions, etc.?

I've just separated it to https://github.com/lecle/aloxide/issues/8

[flowersinthesand]

Closing as researched and applied to our project