Solana is a blockchain protocol that has gained significant attention in the cryptocurrency community. This work examines Solana’sconsensus protocol and its reference implementation.In this paper we try to get an understanding of the Solana protocol. However, this is not so easy because the publicly availableresources are insufficient to specify the details of the protocol. Moreover, the implementation has deviated in undocumented ways fromthe available protocol design description. Thus the consensus rulesand their implied security properties remain unclear.We evaluate a number of experimental scenarios in a local Solanatestnet. These tests seem to confirm our basic understanding thatSolana does not fully achieve consensus. In this paper we show howa single malicious validator, once elected as leader, might be ableto halt the Solana blockchain. We also observe some inconsistentbehavior, which is not readily explained by any of the consensusrules we are aware of.
Tests 510 ((67%, 16%, 17%), (66%, 17%, 17%) and rotations): When comparing the outcomes of tests 57 with those of tests 810 we see no different behavior which leads to the conclusion that in this scenario a supermajority has no effect. We also have the same forks occurring as in the previous tests, these being: 1) (Tests 6.2, 6.4, 9.1) Fork [4, 5]: See 1) of test 3. 2) (Tests 6.2, 6.5, 9.3, 10.1) Fork [4, 8]: See 2) of test 3. 3) (Tests 6.2, 6.3, 6.5, 7.1, 7.5, 9.2-9.5, 10.1, 10.2) Fork [5, 6]: See 3) of test 3. 4) (Tests 7.1-7.5, 10.2-10.5) Fork [4, 12]: See 3) of test 4. 5) (Tests 7.2-7.4, 10.3, 10.4) Fork [5, 9]: See 4) of test 4. 6) (Tests 7.2-7.4, 10.3, 10.4) Fork [6, 7]: See 5) of test 5. As in test 4.4, we reach the same block stores in tests 7.1 and 7.5 with validator 2 again abstaining from voting after slot 11. In tests 10.2 and 10.5, however, we have the same block store but now with two abstaining validators 1 and 2.
id: 2b88234a29985c264cf59aa31fddcdf3 - page: 5
ICDCN 24, January 47, 2024, Chennai, India Kniep, et al. Figure 2: Visualization of the validators state in the equal case. Colors indicate the block producer. Figure 3: Visualization of test 4.4. Colors indicate the block producer. A possible explanation for this behavior could be that now both validators voted up to slot 11 and hence introduced big lockout timers for both of them rather than one of them stop voting earlier. Here it is unclear how this behavior was influenced by this stake distribution change.
id: adc42b45444e3092c1fe7668bb16378c - page: 6
Tests 1116 ((39%, 30%, 31%), (38%, 31%, 31%) and rotations): Examining the outcomes of these stake distributions, we see that consensus was never reached. Possible explanations for the occurring forks are the following: 1) (Tests 11.1, 13.4, 13.5) Fork [3, 8]: Here only validator 2 rolls back to slot 2 to create a fork while validator 1 continues producing and voting on its fork. Validator 2, however, is unable to roll back its vote to slot 2 due to an implementation bug, which is examined further in Section 5. In addition to forks, we also have completely different voting behavior. Possible explanations for these behaviors are the following: (Tests 11.1, 13.4, 13.5) The highest staked validator continues to vote on its fork while the second validator abstains from voting right after its own slot 3 and the other remaining validator voting up to the last slot of its schedule: Validator 1 is unaware of the duplicate and simply con-
id: dc38c78d583d4d14fee2fb62b77ad0b5 - page: 6
Validator 2 started a fork at slot 2 because it rolled back but is unable to switch its vote. Validator 3 forks at slot 3 because it is unable to validate any blocks of validator 1. Then after slot 15, it wants to switch forks but is unable due to not reaching the duplicate threshold. 2) (Tests 11.1, 13.4, 13.5) Fork [4, 12]: See 3) of test 4. 3) (Tests 11.2, 11.4, 11.5, 14.3-14.5) Fork [3, 8, 12]: Validator 1 continues on its fork, unaware of the duplicate in its slot 3 while both validators 2 and 3 manage to roll back to slot 2 and create a fork. (Tests 11.2, 11.4, 11.5, 14.3-14.5) The first, i.e., highest staked validator continues to vote on its fork while the other two validators stop voting right after slot 3: Validator 1 continues on its fork, unaware of its dupli-
id: 62dce1fb6943bf97544edd312fb3ae7f - page: 6