Hi Secret Community,
This thread is for kick starting a discussion for the tradeoffs around compartmentalizing.
As you may know, I was part of a team (sgx.fail) that did whitehat security vulnerability research on SGX applications, and in particular we found that Secret’s master decryption key could be through xAPIC vulnerability, after working together on the disclosure the attack window was closed up (secret’s post).
It’s possible that something like this could happen again (let’s hope not, but it’s tough betting against it). Even among TEE-based smart contracts, Secret’s architecture presents a really large attack surface. So we should consider hardening along the lines of what Phala and Oasis do, based compartmentalization (ekiden research paper).
In Secret, anyone can join the network with an enclave, i.e., there is no stake requirement or voting/approval requirement, the amount of nodes that could potentially be attacked using a future SGX vulnerability is quite large. Obscuro takes the same approach. In contrast, Oasis and Phala limit the access to key material to staked/bonded nodes — and even then, only on a contract-by-contract basis, with the master keys stored by an even smaller number of trusted (and eventually secret-shared) key manager nodes.
On the other hand, limiting who gets access to the key material has several disadvantages. It means taking a hit in decentralization, as running a node will be permissioned. You’ll either need to have enough stake to be a validator or to be whitelisted. It reduces competition and diversity, and could potentially lead to a reduction in the performance of the network due to a smaller number of nodes providing services to dApps. In addition, any attempt to build in a mechanism which ‘shards’ the keys across contracts/validators, would potentially affect the network on several levels. Composability would be a big concern (i.e., contracts calling contracts), liveness/performance would be impacted since now nodes would need to fetch keys from other nodes to actually process blocks, and the development effort involved would be extremely high and would deprioritize other things.
This is a tough tradeoff between decentralization/liveness/performance vs the increased attack surface and potential privacy breaches.
IMHO this is the most strategic issue to tackle, and one of the most controversial ones both within SCRT Labs and at the community at large.
I’m VERY curious to hear what people has to say about this. Andrew did a great a recap of the pros and cons already.
I can say that my opinion is generally: (1) No to sharding keys on a contract-basis, as that would really mess up composability. I honestly think the only reasons other networks are saying they’re doing this is because they’re not live and don’t have any users; (2) Yes to a minimum stake + whitelisting to run a validator/be a node provider; (3) Yes to future research on how to limit # of keys each enclave gets (not exactly sharding, more like each validator holds a cache and requests keys as needed).
I know many (maybe even most?) don’t agree with me on this though. The reason I push for it, even at the price of some decentralization, is because it upgrades the security model and adds an ‘economic security’ layer.
IMO any solution that’s not fully permissionless is just not pushing the envelope enough. A minimum stake + slashing mechanism for nodes is an interesting idea though.
Another interesting idea is to run the unprotected side (the cosmos app + rust glue) in an enclave just to include it in the attestation/registration process. This would eliminate the spicy printf problem but not the SGX jailbreak problem.
The concept of key manager nodes and various node types is indeed intriguing. A number of existing networks, such as relayers on Cosmos SDK chains, Horizen (formerly known as ZenCash), and others, have already implemented different degrees of node differentiation. One potential approach for our network might involve requiring a long-term, larger self-bond along with distinct slashing mechanisms for more complex nodes. This could make some nodes considerably easier to run, thereby encouraging greater participation from prospective node runners.
However, given the multitude of ways to execute this strategy and the diverse motivations behind each approach, it would be valuable to examine a practical implementation of a multi-node system specifically tailored to the Secret Network, supported by the technical rationale for the chosen approach. At the very least, I’m fine with keeping one node type and continuing down this path, but very curious on what the other approach would look like here.
I find it difficult to support creating another layer of requirements to join the Network.
We have to remember that SCRT, by virtue of Tendermint and SGX being a little more difficult to scale, will always have a pretty tight validator set in terms of absolute number.
Consider that all of the exploits Andrew has found would likely not have happened if we had gated the Network. By gating malicious actors, you likely gate some positive actors who don’t want to accept the barrier to entry in the first place.
I disagree with this rationale for supporting ungated-mainnet. Having a public test network that’s ungated was the most useful thing for us to work on, pulsar-2 was especially suitable because of having block explorer support and even real swap applications in it. Bug bounties / or even automatic “honeypot contracts” for testnet demonstrations are also good motivation
Thanks Andrew for your research and time spent on these complex issues. I appreciate you bringing these matters to light, so that we can discuss them openly as a community.
I am not technical, but is it possible to design architecture that is a hybrid of solutions mentioned above, that 1) provide a trusted group of individuals with the master keys (still rotated periodically) and 2) provide “guest” keys that are temporary for members that are newer that still need to gain the trust of the community.
If this is possible, how can we monitor the activity of the new members and allow them to prove their trustworthiness?
This scenario is akin to a “temporary” pin code used to allow our guests into our house, when my family members have their own master pin.
I think compromising decentralization and permissionlessness for a lower attack surface is unacceptable to me. Why are we using a blockchain then? Maybe I’m being too dogmatic, but for me the foundational goal of these systems should be something that anyone can use/join and with no central point of failure. I think Tendermint is already a significant compromise on the above imo, further limiting things feels like we are just wasting our time.
We should accept and embrace attacks as a way to build a sturdier system.
Also not to derail the convo, but I’d be more interested in discussing this as part of the TEE + MPC scheme thats been suggested (as part of scrt 2.0) to protect the consensus seed. e.g At what number of participants/nodes does the MPC become a performance limitation (is it too centralizing?), how often would we rotate (central point of failure?), etc.