I am trying to understand what the purpose of the scope in multi_index is. Does it have performance/cost implications to put all the rows in the same scope and then just query using the keys? A thorough explanation would be nice since I try to make an educated decision on what to use :).

I am mainly asking because I have an index that I need to have random access to by two fields. Currently I use one of the keys as scope which does not allow to query the index by the other field.


UPDATE: It seems Block.one does not plan to implement the functionalities necessary for scopes to actually make any difference in performance, which renders scopes useful only for separating your data for easier access. Reference: https://github.com/EOSIO/eos/issues/4357

Yes, basically scope exists for 2 reasons:

  • Allows you to separate records that do not need to be listed all together into separate tables, so that finding the right information becomes very quick and easy.
  • More importantly, they delimit the parallelism that can occur when reading/writing to the DB. Read/write locks will be managed by the EOSIO software based on scopes. In practice this means that putting everything on the same scope would make it harder for the software to run more of those transactions in parallel.

This are the two main things regarding scopes, but I don't know the exact details of implementation. You can find more details here: https://github.com/EOSIO/eos/issues/1040 (for context, the scopes that a transaction should use used to be explicitly given by the user when sending the transaction).

For your case, it sounds like you will want to list the whole collection of data together, so you'll need to put it all in one scope and one table. In the other hand, for allowing better parallelism for your contract execution I think it would make sense to store most of the data (and the data that will change the most) in separate scopes, and use a separate reference table to query the whole collection. The reference table would just contain the primary/secondary keys and the scopes under which you can find the rest of the data. The frontend then would need to query the reference table and use the received keys/scopes to query the data of each of the rows separately. More requests, but better on-chain performance.

  • Hey! Is the update message in your response still up to date? It seems multi threading has been added now? Am I wrong? If so, does using the scope of multiindex tables lead to an increase in performance? See: github.com/EOSIO/eos/issues/4357#issuecomment-580174066 – mschoenebeck May 3 at 23:56
  • 1
    @mschoenebeck sadly, it's still up to date. They've added multi-threading only for running various aspects of the nodeos software itself, but not for parallel execution of transactions, so there is still no usage of scopes or sharding. – Andres Berrios May 4 at 10:12

August 22nd, Developers Telegram Channel. Todd Fleming is a contributor to eosio

Todd Fleming: scope originated as part of sharding, which was later dropped.

It can sometimes make indexing easier. Other times it doesn’t have any real value.

In other words, the sharding method of enabling parallelism detailed in the whitepaper is no longer applicable, and parallelism will be achieved via sidechains. This doesn't make use of scopes, as they're different chains which are identified by their own properties, so scopes are just a tool to separate your tables for your own convenience and indexing preferences on one chain.

At the moment, sidechains are not documented in the whitepaper or in any EOSIO resources besides a rather old post from Dan on IBC, so I assume the main resource for reading about them remains the original paper that introduced them.

Back, Adam, et al. "Enabling blockchain innovations with pegged sidechains." URL: http://www. opensciencereview. com/papers/123/enablingblockchain-innovations-with-pegged-sidechains (2014).

  • What does he mean by 'sharding'? Is this the second bulletpoint in the accepted answer? – eclipse Aug 23 '18 at 8:36
  • Yes, sharding is splitting data to enable parallelism of processing – Ami Heines Aug 23 '18 at 9:02
  • @eclipse yes, i believe that second bulletpoint refers to sharding. I edited my post to add some explanation – confused00 Aug 23 '18 at 9:15
  • Is multi-thread parallelism (aka sharding) officially dropped?? Did they announce it officially or just on conversations on telegram chats? I've been optimizing my contract code to be sharding-ready for when they implement this! I would like to know the reasons for it being dropped, since it still looks like an amazing way to scale up transactions per second. Do you have any links? – Andres Berrios Sep 2 '18 at 13:53
  • @AndresBerrios i don't think they made any official announcement. i'd open an issue on github to ask if you want to get an official response – confused00 Sep 2 '18 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.