Roadmap
In this section we will be sketching out the roadmap as it pertains to the Secret Network layer 1 and its development. For an overview of the entire Secret Network ecosystem you can refer to the Secret Network monthly roadmap blog.
The next update for Secret Network will bring an updated version of the Secret Contract library to CosmWasm V1.0. This will bring IBC smart contract compatibility and Interchain accounts to Secret Network, enabling the cross-chain privacy hub vision. The upgrade will be tested in phases with the first test being a local testnet planned for early July and deployment to the main testnet a few weeks later. The CosmWasm V1 upgrade is expected to launch in august.
Learn more about this upcoming update from this Agents of the Roundtable podcast with Assaf and Lior from SCRT Labs.
When initially developing secret contracts a decision was made to go with WebAssembly (WASM) engine wasmi - a slower, older engine that was made for SGX (the core technology that enables privacy) - rather than undertaking long development to adapt a more performant engine. This allowed the network to launch faster, and now it is catching up with the newer more performant engines.
The team is aiming to do the WASM engine replacement in phases and start with a replacement to WASM3. The implementation of WASM3 can be done faster and will bring a ~25x TPS increase for smart contract executions. This feature is expected to launch in Q4 2022
Over the long term the intention is to replace the current WASM engine with the vanilla CosmWasm’s WASM engine, Wasmer. This is going to be a difficult task, as the engine that runs the Secret contracts is tightly integrated with many system components. This new engine would bring a smart contract TPS increase of ~200x. The team is confident they can pull this off for a release in 2023.
You can get more information regarding scaling options and roadmap items for Secret Network from this discussion with the Core developer from SCRT Labs Assaf.
Long term the SCRT labs development team is looking into enabling Secret tokens for gas payments. This would bring better privacy to the Secret Network as interactions would no longer be noted on chain if users pay with Secret Tokens.
This idea comes with several development challenges and changes to the standard Cosmos SDK module. No expected date is set for this feature.
SCRT labs is actively researching for ways to add features of HME and sMPC into the Secret Network protocol. The team is very familiar with these methods but sees no way to offer a scalable fully software based blockchain encryption protocol at this moment in time. Further research on HME might one day make it reasonably fast for Generalized compute but at this moment in time that is not feasible.
The team is however looking into deploying logiv for threshold signing or MPC as an additional security metric for Secret Contracts. With this infrastructure contract developers might choose to add this secondary layer (on top of SGX) of privacy to further protect the most sensitive content.
A good use case for this is further protecting private or encryption keys that are hosted on Secret Network. Jackal, AlterDapp, Serenity and more applications all use private on-chain storage for private keys in this way. These keys don't have to be accessed often and are a very small size, the scalability concerns of MPC are therefore less important.
Combining SGX and Software based encryption in this way allows for a very composable infrastructure providing privacy at different security levels and scalability.
An active idea amongst the SCRT labs developers is to use the Secret Network deterministic entropy as a way to scale Secret Network. All validators have access to the same deterministic network random-number generator. Outside of the enclave of any validator the deterministic component is unknown. Because of this every validator can generate the same randomness at any given time.
When heavy computations come in the network could immediately agree that only one validator would run that given computation. Any other validator can still validate this transaction. The same can be done when a Secret Oracle is requested from the chain. The separation of these transactions is different from the standard Tendermint implementation where every validator does the compute for all transactions. This structure would significantly further scale Secret Network as it acts as an L2 rollup inside the native layer 1.
The same logic as proposed above can be used for one validator doing non-deterministic actions like issuing a TLS connection to the outside world. The result of any interactions (eg. interim bridge) over this connection can than be signed by the validator and submitted by any user on-chain. This authenticates the Oracle.
Last modified 3mo ago