Ola: The Programmable Privacy Platform for Ethereum

TL:DR

1. Ola is the first Programmable Privacy platform based on ZKVM and ZK-ZKVM, committed to bringing controllable, optional privacy to Ethereum.

   
   

2. Ola achieves better programmability by implementing a General-Purpose Smart Contract Language based on the Instruction Set Architecture (ISA) rather than the circuit or constraint language, i.e., DSL.

   
   

3. Ola’s privacy design includes a robust key management system, a UTXO-like account structure, and a constraint logic other than proof of programmability.

   
   

4. Developers and users can easily utilize Ola for various purposes, including contract deployment, data control, etc.

   
   

5. The public testnet of Ola aims for a Q4, 2023 launch.

The attributes of a public blockchain ledger are truly remarkable. It is transparent, decentralized, and immutable, revolutionizing the traditional way of establishing trust.

Its completely decentralized consensus protocol ensures that the latest stored state is always correct, making it highly trustworthy.

Meanwhile, Web3 is a protocol built on blockchain technology that aims to achieve decentralization while also empowering users to truly own their data (data ownership).

This is a fundamental goal of Web3, as blockchain technology enables decentralization without the need for trust in third parties.

Additionally, privacy can give users control over their data, which can address the common issue of data being used and profited from without their consent in both Web2 and blockchain fields.

User privacy can be roughly divided into two parts: Identity Privacy and Data Privacy.

Decentralized Identity projects (DID) aim to solve the problem of user identity privacy by allowing users to prove their identity without revealing any key information about themselves.

Data privacy, on the other hand, mainly addresses the protection of data for users on blockchain.

Ola, as the first Programmable Privacy platform based on ZKVM and ZK-ZKVM, is committed to bringing controllable, optional privacy to Ethereum, the largest public blockchain.

A Programmable Privacy platform consists of two critical technical components: Programmability and Privacy. This article aims to introduce the design principles behind Ola from these two perspectives.

Programmability

Why ZKVM?

There are currently two forms of Programmability: ZKDSL and ZKVM. ZKDSL forms, such as circom, halo2, Noir, and Leo, define basic operators that correspond to a circuit unit. Syntax rules are also defined on top of these operators, allowing for the creation of programs.

In contrast, ZKVM forms, such as Risc0, Miden, and OlaVM, implement a General-Purpose Smart Contract Language (GPSML) based on an Instruction Set Architecture (ISA).

GPSML not only defines basic arithmetic instructions but also includes loops, calls, return instructions, memory, and storage read and write instructions, resulting in a higher level of language abstraction and programmability than DSL.

The different processes between ZKDSL and ZKVM are shown in the following figure:

Essentially, a DSL language is a circuit or constraint language. The main purposes of using DSL are:

1. To avoid developers directly writing the underlying circuit constraints, reducing the threshold for writing circuits and zkDapps.

   
   

2. To make it easier for other developers to understand the constraint logic of the circuit. DSL offers better readability than low-level circuits.

This is also the reason why the Polygon Hermez team defined the PIL language, which directly uses PIL to write micro-ops and then calls circom-libs to convert them into underlying constraints.

Therefore, the DSL language is more suitable for expressing simple calculation programs and cannot be used to write smart contracts. Smart contracts often involve relatively complex logic. To implement such logic, a higher abstraction language is required for better programmability.

Thus, Ola chose to implement better programmability based on ZKVM, OlaVM, and a custom smart contract language, Ola-lang, which enables developers to implement more complex dApps.

How to Achieve the Fastest ZKVM: Tips and Tricks

Although ZKVM-based systems are a better choice for programmability, the performance of the prover is still a crucial aspect to consider.

Poor prover performance can directly affect the TPS of the entire system, resulting in a poor user experience and negatively impacting the system’s overall construction.

Therefore, it’s essential to build a full-featured, zk-friendly ZKVM to ensure optimal performance. Ola aims to become a high-performance ZK-ZKVM platform, and its key technical features are shown in Figure 3:

1. How to achieve smaller execution paths: By utilizing a register-based VM design and incorporating support for non-deterministic features.

   
   

2. How to design more concise & succinct constraints: By utilizing an Algebraic RISC Instruction Set Architecture to reduce the number of instruction sets and decrease the degree of the constraint system.

   
   

3. How to implement and optimize the fastest ZK algorithm: By utilizing the Starky algorithm ( STARK + Goldilocks field) and the fastest blake3 hash, among other techniques.

Specific technical details can be found on olavm/docs.

Privacy

As for why the UTXO-like model is more suitable for privacy rather than the Account model, we won’t go into too much detail here. Please refer to the Aleo paper (page 11) to learn more. Ola will mainly adopt the following design in terms of privacy:

1. Robust key management system.

   
   

• One-time signature: To protect the sender’s address information, Ola employs a one-time signature design, where each transaction is signed using a unique public and private key pair.

• One-time address: Ola also utilizes one-time addresses to enhance sender anonymity. The receiver’s address used to accept a transaction changes for every transaction.

• Updatable view key: The view key allows the sender to view the transaction information, which may be required for regulatory scrutiny or for personal data sales. To ensure privacy, Ola’s view key can be updated once it has been exposed.

2. UTXO-like account structure — Note-based.

• Following the concept of Zcash, the input and output of each transaction is represented by a Note. This structure enables easy hiding of transaction sender and receiver information.

3. Constraint logic other than proof of programmability. This requires:

• Ensuring computational integrity of the commitment

• Ensuring the effectiveness of the commitment

• Cost the computational integrity of the Note Nullifier

• Verifying the validity of the signature

• Ensuring computational integrity of one-time addresses

• Ensuring computational integrity of the generated note

• Proof of Programmability -This includes off-chain computation and proof of public function (Account-based) as well as off-chain computation and proof of private function (Note-based).

Figure 4 shows a simple comparison of dApps-specific privacy and Programmable Privacy, which is broadly similar except for the circuit logic for state transitions:

Benefits for Developers and Users

Ola’s long-term vision is to bring Programmable Privacy through its ZK-ZKVM platform, which offers the following benefits to developers and users:

1. For Developers

• Developers can freely choose to deploy public contracts (Account-based), privacy contracts (Note-based), and ordinary contracts (Account & Note-based).

  
  

  For public contracts, Ola is a ZKVM.

  For privacy contracts, Ola is a ZK-ZKVM.

  For ordinary contracts, Ola is a ZK-ZKVM or ZKVM, depending on the user’s transaction type

  
  

• Transfer of assets between public and private accounts

  
  

  Intra-contract, no bridge contract is required, supported by default.

  Cross-contract, a bridge contract is required.

2. For Users

• For ordinary contract types, users can freely choose the transaction type.

• For public/private contract types, users can only execute transactions of the corresponding type.

• Users have a view key to disclose executed private transactions.

• Ola supports the update of the view key so that after the view key is exposed, the privacy transactions executed by the user in the future will always be parsed.

• Ola supports asset transfers between public and private accounts.

Figure 5 depicts the infrastructure of Ola, assuming that the proof is not generated by the end user. It is important to note that ideally, privacy transactions are assembled into a transaction and sent out after the end user generates the proof.

However, in reality, most end users have limited computing power, and therefore, it is necessary to delegate proof generation to a node with stronger computing power.

While the transaction information may be exposed to the proxy node, it can not forge a successful transaction based on this private information due to the one-time signature design scheme.

Looking Ahead

Ola has completed the proof-of-concept (PoC) implementation of OlaVM and Ola-lang for programmability and is currently undergoing continuous rapid iteration. Additionally, the design of the privacy module is also being internally promoted.

We plan to release the programmable privacy public testnet (ZK-ZKVM testnet) in Q4 2023. However, before that, there is still a lot of work to be done.

Ola has already established a Discord community, and all developers and users are welcome to join and contribute, which will be rewarded with Ola points and multiple perks and privileges as the Ola ecosystem grows stronger.

About

This article aims to provide an update on the latest developments and news related to Ola and zero-knowledge cryptography, which has the potential to revolutionize the way we approach privacy and security in the digital age.

We will continue to monitor and report on the latest developments in this field. Please write to <[email protected]> if you’d like to join or partner with us.

Photo by Jason Dent on Unsplash