*Note: This review and score is purely based on the information disclosed by the validator service and the scoring rubric.
Last Updated: Nov 6, 2019
About Sikka
Sikka’s validator service operates on the Cosmos blockchain. Built by core contributors to the Tendermint and Cosmos PoS protocols, Sikka differentiates itself with deep technical understanding of PoS protocols and governance. Sikka presently offers zero commission validation services, and is proudly based in Berkeley, CA.
Supported Chains
- CosmosHub
- IRISnet
Future Chains
- Kava
General Ratings:
| Overall | 76 |
| Company | 89 |
| Code/Infrastructure | 58 |
| Operations | 81 |
Company:
Team Background (62.5/100)
- Full-Time/Part-Time (5/10)
- Prior Blockchain Dev/Impact (10/10)
- Systems Experience (0/10)
- Recognizability (10/10)
Current Voting Power (100/100)
- Total Staked: (10/10)
- Unique Self-Bonders: (10/10)
- Commissions: (10/10)
Historical Metrics (100/100)
- Uptime (10/10)
- Proposals (10/10)
Bonus (+5)
- Legal Compliance/Insurance (0)
- Innovations (+5)
Team
Sikka is founded by Sunny Aggarwal and Dev Ohja. Both Sunny and Dev are currently part-time on the Sikka project, as they both also work together at Tendermint Inc as contributors to the Tendermint protocol.
Sunny boasts a deep background in Proof of Stake research; largely designing the Proof of Stake protocol that Cosmos is based on today. Dev boasts a background in cryptography and privacy preserving technologies; working with UC Berkeley Professor Alessandro Chiesa on constructing a novel zero-knowledge proof system called Aurora. Prior to Tendermint, both Sunny and Dev were active members of the Blockchain at Berkeley group, as co-founders and researchers respectively.
Sunny is currently the host of the Epicenter podcast (link here). Links to Sunny and Dev’s Githubs can be found here.
Stake
Sikka is presently the #3 validator on the Cosmos hub by delegation with ~11.7M atoms delegated. At time of writing, this translates to approximately $50M USD. Much of these funds are delegated, and come from Sunny and Dev’s reputation in the Cosmos community (as public faces of the Cosmos project and core developers to underlying Cosmos protocols).
Sunny and Dev additionally attribute much of their attractiveness to their 0% commission rate (now currently 3%), vs industry-standard 10%. This 0% commission rate was selected due to the fact that neither founder is presently full-time on the project. Additionally, due to the fact that Sikka’s validator is based in the Berkeley Data Center, Sikka incurs close to zero hosting costs.
Historic Metrics
Sikka has maintained 100% uptime since its entrance into the active validator set in the Cosmos genesis block. The company has 5.74% of the network’s voting power, and has been trending upward since their conception.
Of the eight proposals on the Cosmos Hub thus far, Sikka has initiated two (25%). One of these proposals has passed, while one is currently pending.
Community
Sikka describes itself as “the people’s validator”. This is attributed to their low commission rates, and unique governance model. At time of writing, Sikka is presently developing SikkaDAO: a Decentralized Autonomous Organization that will govern and earn 50% of future validator commissions. SikkaDAO’s token will be rewarded to delegators over time, meaning that the longer one delegates to Sikka, the more tokens one will earn.
Slashing Procedures
In the face of a slashing event (via double-sign, missed blocks, or more), Sikka’s SikkaDAO will be responsible for governing procedures. The DAO may vote to compensate delegators, or provide no compensation or insurance. Presently, however, Sikka offers no compensation policy.
Code/Infrastructure
Validators (33/100)
- Failover (10/30)
Sentries (83/100)
- Private Peering (10/10)
- Agreements with other Validators (0/10)
- Sentry Scaling (5/10)
- Snapshotting
- Backup Strategy
Sikka presently operates one validator node, located in the Berkeley Data Center. No failover validator is in place at the time of writing. In the future, Sikka intends on developing an auto-failover mechanism, with a priority on architecture that is “simple” and “slash-minimizing.” Sikka is of the opinion that most existing failover mechanisms are over complicated and/or overkill, and will be developing a mechanism that is safe against any network level attack at a hackathon in coming weeks.
Sentry Architecture
Sikka presently deploys a standard sentry architecture with private peering. Sentries are exposed on a public P2P network for RPC’s, while the Sikka Validator node only serves requests from known Sikka sentries. Sikka additionally maintains one private sentry that is privately peered to validators whom sikka has personal relationships with. This is done to maintain secrecy of IP, while promoting diverse sources of information.
Sikka presently has no auto-scaling mechanisms. At time of writing, the team is in the process of implementing automatic snapshotting, however this remains as work to be completed.
Custom Code
At time of writing, Sikka has not developed any custom code. This is as most of the team’s time is spent developing the software for the PoS system itself. Accordingly, delegators utilize third-party block explorers and wallets to stake funds with Sikka.
In the future, all of the SikkaDAO code will be open source.
Operations:
Monitoring Tools (50 /100)
- Network Level (5/10)
- Hardware Level (5/10)
- Paging (5/10)
Single Point of Failure (100/100)
- Multi-Cloud (10/10)
- Multi-Region (10/10)
Key Management (75/100)
- HSM Selections (10/10)
- Smart Key Management (5/10)
Validator Access (100/100)
- Physical/Remote (10/10)
Monitoring Tools
Sikka uses standard monitoring tools, specifically looking at their validator and sentries global resource stats. Event triggers include but are not limited to: CPU triggers, memory triggers, network bandwidth, and more. If a sentry were to experience downtime, Sikka has configured notifications from cloud providers.
Upon conversation with the team, Sikka has shared that monitoring tools are one of the core areas they would like to improve in.
Single Points of Failure
Sikka operates sentries across a number of cloud providers, including AWS and Google Cloud. Within each provider, Sikka uses multiple regions, mitigating issues caused by geography.
Key Management
Sikka presently uses a YubiHSM2 as their Hardware Security Module. This device signs blocks before but does not allow any custom code, preventing hardware-based double sign protection. The Tendermint KMS in front of the HSM provides software-based double sign protection.
Validator Access
Sikka presently utilizes the Berkeley Data Center to secure its physical validator server. This Data Center is protected by 24/7 security, and is connected to the UC Berkeley campus backbone network via two separate 10-Gigabit trunks for high availability. Sikka’s physical servers are kept under lock and key, and only made accessible to select critical personnel.
Physical attackers solely have the ability to kill validator liveness, but cannot recover any critical private keys. This is due to the design of YubiHSM2.
DoS Protection
Sikka boasts 1GB/second DoS protection. They rely on their ability to adaptively launch sentries in the face of a serious DoS attack. This would have to be manually done across cloud providers given current configurations.
Introspective Analysis
When prompted, the Sikka team gave the following analysis on their current technological and operational priorities:
Sikka is focused on developing three core items.
1) Sentry Automation
– This includes developing automatic snapshotting, as well as auto-scaling solutions
2) A Secure Auto-Failover Mechanism
3) Smarter HSM’s
– Sikka has spent some time researching smarter HSM’s – specifically HSM’s that prevent malicious actors from passing one’s private keys to different things to sign. Right now, physical attackers are unable to steal Sikka’s private key, but, if someone is able to SSH into their machine, they can tell it to double sign a block. This is because double sign protection is in Sikka’s software presently, not the physical machine itself. If there exists an HSM that can bring double sign protection into hardware itself, that would solve a large problem for the community.
Here is a list of our full validator rankings!
