Date: January 28th, 2018 11:13 AM
Author: Duck-like trump supporter
The Zilliqa team's write-up of IOST vs. ZIL:
"Comparing Zilliqa to IOS
The IOS project proposes a scalable blockchain platform that employs the idea of sharding to scale. IOS assembles primitives from several academic papers such as the ones that propose Collective Signing, ByzCoin, RandHound-RandHerd and OmniLedger. More precisely, IOS adopts the idea of signature aggregation from Collective Signing, the idea of running pBFT as a consensus protocol with signature aggregation from ByzCoin, the concept of transaction and state sharding from OmniLedger and uses a bias-resistant distributed random number generator from RandHound. In fact, OmniLedger itself combines other works and hence, IOS is very close to OmniLedger. The designers of IOS also mention this in the whitepaper.
ZILLIQA employs some of the ideas from Collective Signing and ByzCoin and hence it bears some similarities with IOS. The two projects however differ in the following aspects:
1. Sybil resistance: The IOS whitepaper does not explicitly discuss the way it prevents Sybil attacks. It appears that Sybil attacks are prevented via a stake-based mechanism. ZILLIQA on the other hand uses PoW for Sybil resistance.
2. Consensus protocol: IOS uses a combination of pBFT and a proof-of-believability (PoB) protocol.
PoB is very similar to a dPoS protocol where a validator proposes a block. Consensus in IOS happens in two phases. In the first phase, a PoB protocol is run among a small set of nodes called believable validators, whereby, they propose a small set of transactions. Later in the second phase, the proposed transactions are verified by a larger set of nodes called normal validators. Normal validators do not verify every transaction proposed by the believable validators. Instead, they first decide which transactions to verify and then they run the pBFT consensus protocol to agree upon the transactions. The whitepaper however does not give a security analysis of the proposed PoB protocol, as a result it is difficult to understand its security properties. ZILLIQA on the other hand uses a standard pBFT protocol for consensus. The safety and liveness properties of pBFT have been well established in the academic literature.
3. Size of the consensus group: A given shard in IOS will have several groups of believable validators. Each group proposes a different set of transactions. However, the size of each group is 1. This implies that it should be fairly easy to single out all the believable validators in a shard and attack them. Moreover, as believable validators are assigned using known metrics such as
reviews, reputation, etc., it is also easy to narrow the set of believable validators beforehand with the available public information.
4. Threat model: ZILLIQA assumes a well defined Byzantine adversarial model where less than 1/3 of the total network is byzantine. On the other hand, the threat model in IOS is not-so-well defined. IOS employs two different consensus protocols namely pBFT and PoB. PBFT assumes a byzantine adversary model while PoB assumes a rational adversary not willing to lose large deposits to subvert the consensus protocol. Hence, it is not clear how a node in the IOS network adaptively switches from one model to the other and whether such a hybrid threat model is justifiable.
5. UTXO model: Since IOS closely follows the OmniLedger protocol, it employs a UTXO-based transaction model to handle inter-shard communications. Roughly speaking, a user creates a transaction with some inputs and outputs. The shards handling the inputs then lock those inputs and issue a receipt certifying that the inputs have been locked and can be consumed as outputs. Once the receipt is issued, the outputs can be validated by the shards handing the outputs. Since, IOS claims to be a blockchain platform capable of running smart contracts, it’s unclear how a UTXO model can efficiently handle smart contracts that need to manipulate global state variables unlike UTXOs that only handle certain inputs. ZILLIQA on the other hand uses an account-based model and hence eliminates any such restriction on running smart contracts.
6. Transaction finality: Since the normal validators do not validate every single transaction, it is possible that a malicious believable validator proposes an invalid (or double spend) transaction that gets detected only after-the-fact. As a result, a committed transaction is not final and one needs to wait for confirmations. Since, ZILLIQA uses pBFT among a large group of miners (the minimum being 600) and verifies every single transaction, transaction finality is guaranteed.
7. Attacks on collective signing: Both ZILLIQA and IOS use Collective Signing (CoSi) for signature aggregation. However, the protocol as described in the CoSi paper is vulnerable to two specific attacks. CoSi implements Schnorr multi-signature. It assumes an honest leader that aggregates contributions from various signers and at the end of the protocol, generates a multi-signature. ZILLIQA
does not assume the leader to be honest. In fact, the CoSi protocol is vulnerable to the following two attacks that we prevent in ZILLIQA.
(a) The first attack assumes that the leader is malicious. At the start of the CoSi protocol, the leader may announce that he wishes to generate a multi-signature on a specific message say “This transaction is a double spend”. However, the protocol does not oblige the leader to stick with this message in the next steps. He may in fact change it to any message of his choice say “This transaction is not a double spend”. There is no possible way for signers to detect this. As a result, the signers may end up signing messages blindly.
(b) The second attack assumes that the signers are malicious. The goal here is to mount a DoS attack. The leader in CoSi performs no sanity check on the contributions sent from each signer. As a result, it becomes possible for a signer to send an invalid contribution that cannot be detected until the end of the protocol when the signature verification is done. This attack works even when a single signer is malicious.
We prevent these attacks by adding extra steps and message rounds to the CoSi protocol both on the leader’s side and the signer’s side. The steps ensure that malicious behavior gets detected as early as possible. It is not whether how IOS prevents the afore-described attacks."
(http://www.autoadmit.com/thread.php?thread_id=3873742&forum_id=7#35259586)