Elrond Platformu İle İlgili Sıkça Sorulan Sorular

Son günlerin popüler projelerinden olan Elrond ile ilgili sıkça sorulan soruları İngilizce olarak derleyip sizlere sunmak istedik.

Elrond ekibine Resmi Telegram adresinden ulaşıp her türlü sorunuza cevap alabileceğinizi hatırlatmak isteriz. Aşağıda Elrond ile ilgili bazı sorular ve cevapları bulabilirsiniz.

Q: What is Elrond?

A: Elrond is a complete rethinking of public blockchain infrastructure, specifically designed to be secure, efficient, scalable and interoperable. Elrond’s main contribution rests on two cornerstone building blocks:

1. A genuine State Sharding approach: effectively partitioning the chain state into multiple shards, handled in parallel by different participating validators;

2. Secure Proof of Stake consensus mechanism: an improved variation of Proof of Stake (PoS) that ensures long term security and distributed fairness, while eliminating the need for energy intensive PoW algorithms.

Q: How does Elrond plan to solve the scalability issue?

A: In Elrond the throughput increases linearly with the number of shards in the network.

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.

The more validators and shards, the more transactions the network can process. Elrond is performing all network services with minimal energy and computational requirements.

Q: What is Adaptive 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.

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

Q: What is SPoS?

A: In general, Proof of Stake (PoS) concept states that a node’s probability to validate block transactions is proportional to how many tokens it is staking.

Secure Proof of Stake consensus mechanism expands on Algorand’s idea of a random selection mechanism for the validators, differentiating itself through the following aspects:

• Elrond proposes an improvement which reduces the latency allowing each node in the shard to determine the members of the consensus group (block proposer and validators) at the beginning of a round. This is possible because the last block’s aggregated signature is used as the randomization factor. In contrast to Algorand’s approach, where the random committee selection can take up to 12 sec, in Elrond the time necessary for random selection of the consensus group is considerably reduced (estimated under 100 ms).

• In addition, Elrond refines its consensus mechanism by adding a additional weight factor called rating. The node’s probability to be selected in the consensus group takes into consideration both stake and rating, promoting meritocracy.

• Elrond uses Bellare and Neven multisignature scheme, which eliminates one communication round in the signing algorithm.

Q: How is Elrond different from other blockchains?

A:

• Compared to Ethereum, Elrond eliminates both energy and computational waste from PoW algorithms by implementing a SPoS consensus while using transaction processing parallelism through sharding;

• Compared to Algorand, Elrond doesn’t have a single blockchain, instead it increases transaction’s throughput using sharding. Elrond also improves on Algorand’s idea of random selection by reducing the selection time of the consensus group from max 12 seconds to less than a second, but assumes that the adversaries cannot adapt within a round;

• Compared to Zilliqa, Elrond pushes the limits of sharding by using not only transaction sharding but also state sharding. Elrond completely eliminates the PoW mechanism and uses SPoS for consensus. Both architectures are building their own smart contract engine, but Elrond aims for EVM compliance to to achieve interoperability between blockchains.

Technical

Q: What hardware requirements are needed for running a node:

A: A typical node will probably need consumer-grade equipment and a super full node will probably need a multi-core server with enterprise level storage capabilities. It is expected that a super full node will need to have the capabilities of a typical consumer grade equipment multiplied by the number of shards. For a single node, the network requirements will need to be around 100Mbit/s download/upload link and for a super full node, the above mentioned requirement should be multiplied by the number of shards. We have tested the prototype on a broad range of equipments and operating systems. We have found that it works fine on a typical machine (i3 processor, 8GB RAM, SSD storage).

Q: Is it possible to coordinate which shard nodes get into?

A: No, the shard each node gets allocated to is random. The new nodes (entering the system during an epoch) are kept in a pool and are allocated to shards at the end of the epoch by a pseudorandom algorithm. The shard assignment cannot be predicted ahead of time.

Q: What is the size of a shard?

A: There is a trade off between security and communication overhead. For security we would want the shard to be as large as possible. For communication overhead to be minimised the number should be as low as possible. Preliminary experiments show that 300-400 nodes per shard would be a good tradeoff.

Q: Is there inter-shard communication?

A: Yes. The processing of cross shard transactions require inter-shard communication.

Q: Will the nodes know if they are in the same shard?

A: Yes, the nodes will know who the other nodes in the shard are.

Q: Do shards have to trust other shards?

A: There is a notarization chain which is always checked for cross shard operations. Some operations can also be verified, like if the cross shard message came from the correct group, and the group has run a pBFT on the message, etc

Q: Your scalability 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 re-claim your stake).

Mining/Staking

Q: How are you rewarding block validators?

A: Our fee structure is still in the research phase but we should have some initial conclusions published soon. The basic challenge is that we are trying to find a feasible way of bootstrapping the network by having a compelling economic incentive for node validators, while maintaining a competitive fee structure. More information on this will be published after our initial research has reached a conclusion. Until then we can share this information: In order to bootstrap the network and maintain a competitive fees structure, we are considering using a gradually decreasing inflation threshold to incentivize a specific (minimum) node participation rate. This will slowly transition to a self-sustained fee structure, ensuring an efficient and secure network. Based on initial calculations, this threshold will never exceed 2.5% per annum.

Q: When are verifiers/validators rated? And how?

A: The leader will introduce a special transaction in the proposed block in which his account will have the rating increased by a small fraction (e.g. by 2 units). If the block gets signed by at least ? validators + 1 then the leader will have its rating increased. The validators will have their ratings increased at the end of the epoch by the following rule: the validators who signed a block that was successfully added to the blockchain will have their rating increased (e.g. by 1 unit). The leader caught cheating on a block (+the validators who signed that block) will be slashed in the following rounds. The slashing occurs if some nodes will emit special transactions with proofs to signal malicious leader and validators and those transactions get included in a block. The nodes that detected the malicious leader will get rewarded and have their rating increased. Any node caught emitting false signaling transactions will have their rating decreased. If rating falls below a certain value, stake slashing will occur.

Q: Is there an estimate of the cost of redistributing a subset of nodes across shards every epoch?

A: The cost of redistributing a subset of nodes between shards consists in the network usage and processing power to bootstrap those nodes. The liveness of the network is estimated that will remain unaffected. We are looking into further optimizations to minimize that cost.

Q: How is cross shard communication handled? Who validates the communication?

A: The communication between shards is made through dedicated channels between the consensus groups. The transaction is dispatched to the sender shard and after it’s being validated and included in a block, a receipt is broadcast along with the transaction to the receiver shard through the dedicated channel. The receipt is signed by the validators group from sender shard and the consensus group in the receiver’s shard can verify the receipt information independently.

Security

Q: Can a shard be attacked?

A: Given enough time and resources, any system can be attacked. One possible way to attack a shard would be to have more than ? malicious nodes into the shard, but this is highly unlikely due to the random assignment of nodes to shards, and the assumptions that no more than ¼ of nodes in the network are malicious.

Q: Are attacks from quantum computing possible?

A: Most of the cryptographic schemes in blockchains today (ethereum, bitcoin, etc) are susceptible to attacks from quantum computers. There have been some advances in cryptography for post-quantum computing and we are investigating this field.

Q: Does dividing the network into smaller shards make it susceptible to Sybil attacks?

A: All nodes are backed by their stake which does not change with the size of shards.

Q: Is it possible to obtain a majority in one shard by pure luck?

A: The probability to get more than ? in a shard is very low < 10^-6 and can be computed by a hypergeometric distribution.

Q: What happens if a group of validators commit an invalid block into a shard’s ledger and it’s the last block of the epoch making the epoch e+1 have an invalid block as that epoch’s genesis block?

A: As mentioned in previous answer, the invalid block will not be accepted by the shard honest nodes, so even if there is a delay in the epoch, one shard having more rounds to reach the end of an epoch with a valid block, this is prefered as opposed to reaching the end of the epoch with an invalid block.

The extra rounds will be deducted from the next epoch, so that delays do not add up. The shuffling of nodes is not affected as the moving nodes are always buffered for one epoch into a waiting list for the shard, together with the new joining nodes.

We are also considering for the last block in the epoch to run a consensus on all the eligible nodes in the shard.

Q: How do 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 produces 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: 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!

A: 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.

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.

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.

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.

Kaynak: Elrond FAQ