Why are you building this?
Blockchains are constrained environments both from a bandwidth (due to gas limits) and capabilities perspective (acting as ”walled gardens”). To retain blockchain transparency and security while extending their functionality with external components like oracles, coprocessors and L2s, the use of cryptographic proofs is essential.
But, if proofs aren’t computed correctly, we face the garbage-in garbage-out problem, and secure scalability isn’t achieved.
Additionally, there is growing consensus on the end game for blockchain scalability being the off-loading of computation and state from L1 to verifiable layers on top, eventually committing only the proofs of their finalized states on L1.
However, there are still burdens holding us back from accelerating the wide adoption of proofs, such as:
- Immature and fragmented proving infrastructure for ZK and non-ZK proofs
- High barrier to entry due to the rapidly evolving landscape (hence steep learning curve and high efforts to keep up)
- Inefficient and gas-sensitive proof verification mechanisms
Key pieces of the puzzle are still missing to achieve our goals as an industry.
Our goal is to make proofs more accessible, secure, and ubiquitous.
Are you launching a new chain?
No.
SafeJunction is designed to be completely chain agnostic and to integrate with any existing blockchain (evm or not) thanks to a very thin integration (the library) composed of:
- chain-specific functions to simplify the process of sending queries (i.e. views or agents) to the SJ engine
- chain-specific functions to validate and read data from the SJ MasterTree
Does it compete with proof aggregators?
Not really, proof aggregation and socializing proof verification costs are not the main focus of SafeJunction.
Proof aggregators are actually very interoperable with our work as they can be seen like efficient collectors of facts that SJ can use as inputs.
What about the trust model?
Thanks to the security-in-depth approach and to the abstraction given by tRUST, you can audit and execute some arbitrary code once and support it with several proof types. This enables a new type of transparent computations to be built and run. While SJ gives access to this feature to anyone, even the SJ engine itself is written in tRUST and inherits those same properties: that’s why each iteration of the SJ engine is backed by multiple outer proofs.
As a result, the system logic’s risk factor is significantly reduced, and with sufficient redundancy configured by apps, it becomes so trust-minimized that it can be considered practically trustless.