@0xShitTrader Good questions, some thoughts
What’s your estimated timeline to launch for each of the milestones? Are they measured in months or in years?
SUAVE as a system will take years to reach its potential. We hope to share incremental releases of particular components along the way, with those releases measured in months.
I’m not so familiar with SGX. How secure are SGX enclaves in practice? Are recent exploits due to implementation-specific problems or due to fundamental issues with the tech? Is Flashbots exploring alternatives to SGX?
Most exploits are implementation specific. The most prominent attacks in recent memory (like the AEPIC leak that affected the Secret network) have been hardware related. There’s also a class of exploits that are caused by how the SGX interacts with the host CPU. Manufacturers like Intel will release patches to address these kinds of vulnerabilities, so the main risk lies in how long it takes for white hats and manufacturers to address the bugs and for developers to upgrade their deployments. Developers can also introduce exploits in the way they program the enclave. For instance, covert channel attacks and side channels can be used to leak secrets if the way the code is executed exposes specific memory access patterns.
It’s likely that these vulnerabilities would be exploited at some point if SGX is run on untrusted computers (ie. where the user has direct access to the hardware). So if we want executors to run their own enclaves, we would have to implement mitigation techniques — like rotating keys, TCB recovery plans, compartmentalization, smart software upgrade processes, etc. — which minimize the impact of leaking data and make that risk tolerable. The new generation of SGX is also migrating increasingly to the cloud, so some of these concerns could be mitigated if we decide to trust cloud operators. That said, this may pose a centralization and censorship risk.
Flashbots is indeed exploring alternatives to SGX, including other TEEs, FHE (Fully Homomorphic Encryption), and MPC (Multi-Party Computation), as well as possible combinations of the above. @metachris would be a good person to discuss this further!
What are the high-level incentives in the SUAVE network?
Users can deposit funds on SUAVE and commit to unlock them if their preferences are met. Specifically they can write smart contracts, which we call bonds, on Suave Chain that validate whether the preference was fulfilled and conditionally transfer a payment if so. These bonds create an incentive for executors to participate in the network.
We are currently iterating on the economics and validator set for SUAVE. At a high level we envision that validators would be incentivized by network fees collected from transactions.
How do you use ETH as the native token of the network? Will this use Eigenlayer restaking?
We don’t currently have plans to use Eigenlayer restaking. For now, we will use ETH bridged to SUAVE Chain as the native token (for paying network fees, executor rewards, etc).
What are the expected block times for the SUAVE chain? Will other chains that use SUAVE for block building be constrained by SUAVE’s throughput and block times?
I think of SUAVE as having a messaging layer and a settlement layer. The messaging layer (ie. mempool) transmits preferences to be executed, while the settlement layer (ie. chain) processes bonds. Latency in the messaging layer makes a big difference in how optimally a preference can be executed — delays could result in missing a slot on another chain, or mean that SUAVE-based builders have access to less orderflow when constructing blocks (eg. if last-minute submissions aren’t transmitted in time). We are actively exploring ways to improve the performance of the SUAVE mempool such that this cost is as negligible as possible.
That said, it’s less likely that block times on the SUAVE settlement layer will be a bottleneck for most use cases. This chain is primarily used to check the results of execution and settle payments after the fact — ie. it mostly processes transactions to (1) initialize bond contracts (2) submit oracle updates about the state of another domain (3) bridge funds and (4) claim the payment from a bond contract after a preference is fulfilled. The block times on this chain only really matter if you have to do one of those things in the process of executing a preference.
We are still designing the mechanism for block building on SUAVE, but it seems unlikely that builders would need to take actions like those while constructing a block. They’d certainly be reliant on the gossip layer to collect orderflow or collaborate with other builders, but they can likely establish and invoke settlement conditions before and after the slot.
P.S. If these questions around building a performant gossip layer or designing an efficient mechanism for decentralized block building interest you, please reach out! We will share a larger set of design challenges in the new year as well.