Telegram Questions & Answers


This topic is comprised of randomly selected Telegram questions with their respective answers:

Q: Are you considering replacing the elliptic curves algorithm with the supersingular one ?
A: Yes, we are examining the current developments in the quantum computing field, knowing that the cryptographic algorithms currently used (not just in Elrond) are not “quantum resistant”. It’s not just D-Wave is working on quantum computers, but also giants like Intel and Google are researching this field. We are also taking a close look at the publications from the National Institute of Standards and Technology (NIST) regarding the standardization of signature and encryption algorithms, including isogeny-based schemes (e.g. supersingular elliptic curve isogenies), aimed at adapting elliptic-curve cryptography to the post-quantum era.

Q: About the cross-shard communication, referring to the state sharding here. Assuming a naive mapping of addresses ending in 1 going to shard_1, etc. Let’s say you have a smart contract at 0x…1, if I want to make a transaction to that, but my account address is 0x…2, how does shard_1 “call” on shard_2 to check my balance for example ? I guess my transaction, since it’s going to shard_1 isn’t a problem, but what about calls or messages done within the contract?
A: The states of accounts are managed by the shard they are allocated to, so as you mentioned, if your account is managed by shard_2, then it’s state is known only to shard 2.

There are two parts here, one would be the cross shard communication needed for validation and execution of transactions, the other part is cross shard state requests which currently are not needed by the protocol, but might be useful in smart contracts.

To explain the first part, I would have to go through how normal payment transaction processing is done.

Execution of transaction (minus in the balance of sender) is done first in sender’s shard, as sender’s shard has all means to validate the transaction, afterwards if validated it is included in sender’s shard block and then the header of the block holding this transaction is sent to be notarized by the metachain. After metachain receives all block headers from shards in a specific round, it creates a notarization block with the hashes of all these blocks and aggregated inclusion proofs for all transactions that have been included so far (including the cross shard transaction in question). This metachain block is sent to all shards, including the receiver shard for the transaction in question.

The receiver’s shard has a list of all cross shard transactions as well (as dispatching of transactions is done to both receiver and sender’s shard), so it can try and verify with the inclusion proof from metachain block if it’s cross shard transactions with itself as a receiver shard have been included. All cross shard transactions that passed the inclusion test, can be executed on the receiver side as well and included in a block. No validation is required as validation was already done in sender’s shard by a consensus group.

For smart contracts it is similar. When you execute a transaction from your account to a smart contract in shard 1, the transaction is validated in your shard_2, as it is the sender’s shard, then the balance for your account is updated. Since smart contract is in shard_1, the execution is done only in the second part, after the transaction has a proof of inclusion in metachain block. The receivers shard does not need to revalidate the transaction, as it has already been validated by a consensus in shard_2, and otherwise it could not have been notarized in the metachain. The receivers shard executes the transaction for the receiver, so balance is updated on the receiver side (plus) and smart contract which has the internal state managed by shard 1 (receiver shard) can be executed.

For other cross shard state requests we can serve them on communication channels (topics in libp2p) with merkle proofs. This can be further optimized but right now it is not the focus. We will come back to this and refine after the first versions of the testnet.

Q: I understand that the SC-functionality is maybe a bit off, but I’ll ask anyway, It might be that the call to the SC doesn’t affect my balance, or are we talking about more BTC-like script types of smart contracts than EVM-ones?
A: There’s a fee in every transaction calling a smart contract so it will affect the caller’s balance. The types of supported smart contracts are EVM like.

Q: And if the execution of the contract depends on something in the receivers shard, the contract is asynchronous waiting for communication from the receiver shard?
A: There are two types of SC (smart contract) we are considering : a) smart contracts with no internal state, providing only functionality and b) smart contracts having internal state that changes between calls.

For type a) smart contracts, we can duplicate these in all shards, so each time there is a call to one of these smart contracts, we can execute the caller’s shard local copy of this SC.

For type b) SCs it is a bit more complex.

Simplified solution: We can enforce that type b) SCs are residing in the same shard with its dependencies at the moment of Smart contract deployment. For this we would need to have a clear direct dependency list stated in the smart contract, but this is actually simple, as each language has a way to “import”/“require”/“use”, etc. external libraries. Afterwards a recursive check of dependencies can be done to decide which shard this SC needs to be allocated to.

It may happen that all dependencies are in a single shard, so then it is easy, the SC will be added to the same shard. Another situation would be that the SC has dependencies in different shards, then a reorganization of SCs is needed so that all dependencies are moved to the same shard. The reorganization of SCs will be done taking into consideration the SC load of each shard (this statistics can be accumulated by each SC call with almost zero overhead) in order to keep the shards balanced. This means that the execution of a SC will always affect a single shard.

This solution looks a bit like “yanking”, the difference is that the trigger for this is a SC deployment, which is many times less frequent than a SC call, so the overhead of moving SC state can be considerably decreased.

We can decide as well to do some periodic checks (would be embedded in the protocol) for shard SC execution load and decide to move groups of dependent SCs between shards in order to balance each shard workload.

We are still investigating further optimizations in the deployment and execution process of SCs in a sharded architecture.

If the SC execution needs information from a different shard, which is not coming from another SC execution, then it indeed needs to wait for the response before it is finalized.

Q: 1. curious about node specification in obtaining high tps - you did the tests with heterogeneous nodes? By this I mean having nodes distributed all over the world with different latencies or more like super fast computers with good internet connection and from same region? 2. What is behind sPoS, I mean there are different implementations of PoS in the industry? What is so special about elrond’s to call it sPoS? 3. What is elrond bringing compared to other platforms claiming to achieve even higher tps like quarckchain, solana and many other claimers? They also claim to use evm as most of the projects do. 4. Is there any other innovation or pain point elrond is tackling? Thanks!

  1. We did our tests with nodes in AWS in 5 different datacenters, distributed all over the world. We are using T2.medium, average dual core 4GB RAM, so medium specifications.

  2. There are different flavours of PoS, all having the constant of “stake locking”. Delegated PoS has some risks like: bribery attacks and semi-centralization. Our selection function of the consensus group takes into consideration both stake and rating and to further increase the security, the consensus group is randomly sampled every epoch.

  3. We are combining our Secure Proof of Stake algorithm with Adaptive State Sharding. Some of the high performance platforms still do PoW. Most other platforms only do static sharding, while we will dynamically change the number of shards based on the number of nodes and network usage.

  4. The most important innovations we are coming with are the scalability that comes from a Dynamically Adaptive Sharding mechanism, Smart Contracts on a State Sharded Architecture and currently under investigation, privacy aspects.

Q: What do you think of the zero revenue model for projects such as BCs. Does the nature of having no foreseeable future revenue model make you nervous about the development of Elrond in 5, 7, or 10 years time?
A: If we take bitcoin as an example, I think things have evolved quite well for them. Despite what you would think now, given all the attacks it experienced, the many obstacles they overcame, bitcoin has gone quite far. Moving one step beyond that, I think ethereum offers an even more instructive example. Once our network is working, its market cap should reach a sufficiently large point that the reserve extends development for at least 5-10 years. At that point, development and governance will likely be very decentralized, funded by the community, and decided by the community.

Q: I know that Elrond wants to rate a block proposer by recalculating at the end of each
round, adding another layer of security by promoting meritocracy. Can you provide more information about how meritocracy is going to be calculated, implemented and how is going to affect the random selection mechanism ?
A: Yes, we want to give slightly more chances to be selected as block proposer to the well behaved nodes. Increases in the rating of honest nodes is happening with a smaller step than the penalization in case of detected malicious behavior, think of this as being hard to gain trust but easy to lose it. Note that the rating has limited influence on a node’s chances to be selected, so no matter how high your rating goes, the chances will be capped. You can think of the selection mechanism as a roulette, where each of the nodes in the shard has a slice, larger or smaller depending on it’s stake and rating. When you spin the roulette you would have higher chances if your slice is larger.

Q: What do you think will have to happen in the crypto space in order to get the magical term of 'wider adoption/usage’?
A: There are many theories here, but adoption can only happen through different apps that solve various problems. I think this will come gradually, as we invent new ways of using what we have currently created. The overarching long term need emerging is a new layer in the internet infrastructure, enabling privacy, censorship-resistence and sovereign digital ownership. As privacy on current web apps is being lost, censorship is applied, and people get manipulated, I expect people to start experimenting heavily with different blockchain applications like the brave browser, these new digital assets nobody can take from them, and other applications giving them again control to their data.

Q: Why did you decide to fund the project through ICO rather than traditional venture capital? What advantages did you see in pursuing this route?
A: Being a blockchain platform with its own native token it makes a lot of sense to raise the funds through an ICO. On the other hand, we see the ICO also as an Initial Community Aquisition effort and we believe the support of the community and of the developers is very important to build a decentralized network. Also take into the consideration that the Proof of stake consensus requires the nodes to stake the Elrond token so the trading and liquidity of the token is important to be reached as soon as possible before and/or immediatly for bootstrapping the network.

Q: Ethereum Foundation researcher Justin Drake recently announced, Sharding to be implemented into the Ethereum blockchain somewhere in 2020. On your roadmap it states that you will launch your mainnet in 2019. Are you on track on delivering your sharding solution sooner than Ethereum?
A: Regarding your second question, this is indeed the case. Our whole point is to move fast with our development and be one the first architectures to offer truly scalable state sharding solution. As things are moving right now, we are advancing at a healthy pace. One of our main advantages is that we have a small, determined and nimble team, able to adapt and move fast.

Q: For the team at Elrond, what would success look like in 3 years for this project?
A: Success in 3 years would mean having 100 dapps working on Elrond, having a geographically distributed developer community of 2000 people contributing, having 50k nodes running a sufficiently decentralized digital governance structure, having Elrond integrated with main payment processors allowing for both online and offline usage of tokens. Either this, or one working application with 1 million users/day.

Q: How many transactions per second does your prototype reach? Is it far of the 10,000 TPS you are aiming for?
A: With respect to transactions per second, the main idea with our architecture is that it enables linear scalability. I.e. scalability which grows with the number of shards(and nodes) in the network. This means that our 10k TPS is not a limit but rather an internal goal or threshold after which scalability will be considered a solved problem. That said, we intend to go much higher than 10k, but want to move on a step by step basis. To come back to your prototype question, our first prototype version had exceeded 1k TPS with 10 shards and 250 nodes, which was approximately in the expected range. Still, we have since moved forward and changed lots of things in our implementation and are moving forward toward releasing the first version of our testnet. This should hopefully happen in about 1,5 months(tentative) or a bit sooner. Results for this should look considerably better(3-5x increase in speed). We will offer some more updates on this as we advance.

Q: While sharding has proven to be a scaling solution to centralized databases, how do you intend to implement a safe sharding solution to your decentralized project?
A: To answer your first question, the sharding solution we chose is based on several points which are supposed to increase the security. First is random sampling, so the nodes forming each shard are randomly assigned to shards. You cannot influence the shard you will be assigned to. Also once a node is assigned to a shard, it will not stay there forever, as we do again a random shuffling at the end of each epoch. This helps us securing the network/shards against colluding nodes. Second point is choosing a sufficiently large number of nodes per shard. This is always a trade off between the security of a shard and the communication overhead in order to propagate the information to all nodes. The assumptions we use are for a typical byzantine model, so from our preliminary tests and analysis, 400 nodes per shard should give us a high confidence against takeover attacks (probability is <10^-7)

Q: How’s does the utility of your token essential to your ecosystem
A: Basically all activity within our network, this includes transactions, running smart contracts, providing services such as staking, or running a node will be fuelled by ERDs.

Q: what is confirmation timed diff between same shard tx and intershard tx ? how do you manage to balance wallet address space with regards to each epoch ?
A: On your first question, the confirmation time for a cross shard TX compared to a intra shard TX is larger by at most a delta d=k*r, where r is the round time and k a constant that will be refined later. This k is expected to be somewhere between 1 and 10.

Per your second question, “how do you manage to balance wallet address space with regards to each epoch”. As you can see in the tree structure, each new shard that is added, splits an original shard address space into 2 equal spaces, half remains with the original shard, and the other half goes to the newly created shard. As the tree grows you can see that you never have more than one level difference between each of the leaves (shards). The address space is balanced out when all shards are on the same level in the tree.

Q: Your scalibility is in the number of transactions or in the number of nodes in network?
A: Both. Adding new nodes to the system should not hinder it but help increase throughput [TPS]. Generally speaking, the scalability we are discussing about is based on several criteria. The system must work well when there are few users and nodes, but more importantly when the system has many users and nodes. Network scaling capability can be measured in this case in time it takes from when a transaction is issued until it is committed to the blockchain, which should not increase with network size or users (it increases TPS instead, which allows keeping the waiting time in certain limits). Another criteria that affects scalability is storage size. When you have high TPS, especially when it comes to sharding, the system must be able to manage the associated data volume (a ledger that grows linearly with TPS) and here we are talking about orders of different magnitude compared to Blockchains like Bitcoin. For this, our solution is Adaptive State Sharding and not just Transaction Sharding (which would have solved the good TPS problem comparable to systems like VISA, but we would still have the storage problem). In addition to this, we also implement a pruning solution to further improve scalability on storage. Another point worth mentioning is energy waste. When the number of nodes in the network increases, one has to consider the operating energy cost, and also the cost of being able to participate in the system (the value of the node itself) - which is lower for us since we are not using POW but SPoS (we leave the whole system upgrade race behind and as long as you are not malicious you reclaim your stake).

Q: Reading through the WP and trying to get my head around how you handle the nothing at stake problem
A: Elrond addresses the nothing at stake problem through a blockchain that aims to evolve without forks. The forking is avoided by the selection process inside SPoS( Secure Proof of Stake), our consensus method detailed in Chapter V, Section 2 in the whitepaper. To overcome nothing at stake and other security problems, SPoS uses two important mechanisms: a) 2 separate selection lists (waiting and eligible) b) 2 selection parameters rating and stake. Our architecture does not encourage a block proposing competition that might produce forks, instead on every round, the group members that are proposing and signing the block are well known. On top of that, after each round the group members may perform a stake slashing for bad behavior using the feedback function based on the ratingModifier. During the development phase, as these features will confirm the mathematical theories and the efficiency of the solution, we will post further results, resistance tests and improvements.

Q: Hi admin, could you please explain state sharding
A: Sharding is a scaling technique inspired by traditional concepts of database optimization. Also known as horizontal partitioning, sharding divides the data into several pieces placed on different environments to be processed.

In a blockchain context, breaking the network into shards would result in more transactions being processed, verified and validated simultaneously. Each sharding level introduces a certain degree of parallelism, as a result, it becomes possible to process more transactions as the network grows. Implementing any sharding type on a blockchain architecture is extremely difficult.

We can identify 3 sharding types (levels):

  1. Network Sharding represents the process of grouping the nodes into shards.

  2. Transaction Sharding takes the complexity to the next level and deals with the distribution of transactions across different shards, but all the nodes keep the entire blockchain into their state.

  3. State sharding represents the most sophisticated part and is described as a mechanism that allows different shards to deal only with a portion of the state without replicating the data between nodes from different shards. A state sharded blockchain can be seen as a network of fully interconnected blockchains.

Adaptive State Sharding – Elrond’s approach – in order to match the current scalability needs, Elrond introduces a novel state sharding scheme with a dynamic model that allows the network to adapt to population and demand changes without compromising security, availability and decentralization.

For a more comprehensive description please read our whitepaper.

Q: Sort of what would differentiate Elrond from a crowded space that you think would make it a success.
A: We’ve spent a lot of time doing research on the current state of the art - theoretical models and existing implementations, while constantly trying to find relevant improvements. The research phase concluded with a scientific whitepaper that presents in an honest manner a complete set of features, unlike most other solutions. There are very few architectures that theoretically aim to achieve a genuine state sharding and the complexity behind this is yet unsolved from a practical point of view. We propose a tree structure that allows Elrond to implement an adaptive state sharding that has the potential to skyrocket the throughput. Proof of Stake is in its early stages of adoption and we have a unique solution to implement a Secure Proof of Stake that promotes a secured distributed fairness mechanism. We strongly disagree with the statement that there are other solutions that are almost identical because there is a serious difference between those who want to do something and present business or marketing arguments and those who have an idea on how to do it and present mathematical and scientific arguments. Also, please see the Related Work chapter in the updated version of the Whitepaper (R1. R6 from 2 days ago) where we underline our advantages. Furthermore, we’ll wait until our statements are validated through the implementation and then we will think about the ICO. Thank you for your interest.

Q: hey, why your domain was registered just 1 month ago?
A: Our initial name was Mithril Protocol, and our domain name This can be easily verified. Indeed, we had many things built around this name but one month ago, as our launch was coming closer, we noticed there were 2 other crypto projects with the name Mithril, one of which was rather well known. This was not the case when we initially chose Mithril.

So, we decided not to create confusion, and changed our name as an emergency decision. We had 3 new options, but decided to go with Elrond, due to its fitting intriguing origin and immediate closeness to Mithril( both are well known names from Lord of The Rings, with dear meanings to us ). Hence the recent registration of as a domain name.