ZK Proofs and Kadena: The Security Model Story (Part 1)

At Kadena, we often highlight scalability and decentralization to differentiate us from other blockchains. However, there is much more to what sets us apart, especially regarding how we approach the zero-knowledge (ZK) proof upgrades we’re working on with Argument. Kadena’s distinctive approach to ZK lies in our security model, which excludes cryptographic methods from smart contracts.

Before diving deeper into this article, you can read this blog post if you’d like a more surface-level understanding for what ZKs are.

Keeping Crypto Out of Smart Contracts

Kadena’s unique security framework and integration of ZK proofs — being built through a collaboration with Argument (formerly Lurk Lab)— instills our principle of keeping crypto out of smart contracts.

From a builder's perspective, capabilities via verifier plugins allow builders to not have to get lost in the trenches of cryptographic code, making it less complicated for them. Capabilities being included in transactions make transactions using ZK more human-readable. Furthermore, transactions are cheaper and more secure because vetted and audited code can be reused.

How Kadena Keeps Crypto Out of Smart Contracts:

• Capabilities
• Verifier Plugin
• Service Provider Interface
• Language Flexibility
• Performance/Gas Cost

Capabilities

Capabilities grant special permissions to our smart contracts. Pact, our smart contract language, only sees a capability, essentially a stamp of approval for a functionality. Pact does not have access to the primitive but merely the capability for the functionality a signature is guarding.

Furthermore, capabilities support single-access smart contracts instead of adding to the multiple-entry smart contract permissions included on other blockchains (e.g., SCAs in EIP-3074). A classic example of capabilities is a coin transfer. On Kadena, coin transfers happen in sets instead of being sent in a signature that the smart contract verifies — as blockchains do, like Ethereum.

Instead of containing a signature in the smart contract itself, Kadena sends a signature with the transaction that goes inside the block, but the signature never makes it to Pact — transactions remain separate from the smart contract. The node verifies it as part of its validation of the whole transaction. We intentionally designed Pact so that signatures and the corresponding keys must be reflected in the hash. This is crucial for security as it prevents transaction malleability.

Once a transaction is validated, it expresses this fact in a capability. Then it tells the smart contract, “Hey, I have verified that someone is granting you the capability to transfer a specific amount of tokens to this account from another account.”

The smart contract knows that the user did a verification as it can refer to that capability, but it only refers to this data. Therefore, the data is not included in the smart contract.

Kadena’s payload data — verified by nodes during consensus — can seamlessly link with capabilities represented in smart contracts, dictating permissible actions for contract execution. This integration ensures smart contracts operate within predefined boundaries established by verified data, enhancing security and reliability.

Verifier Plugins

The Service Provider Interface (SPI) enables partners to integrate verifier plugins — illustrations of a ZK proof’s existence that allows the proof’s data to be included in a block and verified without revealing the data itself. Verifier plugins limit the data in Pact smart contract as our framework doesn’t require all of the data from a proof’s primitive. The output of an SPI and verifier plugin is a capability that states that proof is valid from the verifier plugin and SPI.

A Little Bit of History

In the first iteration of ZK proofs on Kadena, the proofs had to come in as a string of bytes handed to Pact code. Previously, Pact code verified the string of bytes the way you would do it in pretty much every other blockchain, but this was not copacetic. Additionally, it went against the grain of our security model that keeps this kind of stuff out of Pact.

We've moved to verifier plugins. This provides infrastructure for validating external data where the fact of validation is represented to the contract as a capacity. Also, this support extends beyond just the ZK use case. For example, our Hyperlane bridge integration will be the first to utilize verifier plugins.

Hyperlane Bridge Use Case

A verifier plugin is pivotal to delivering Hyperlane’s technology on-chain. The plugin will verify the incoming Hyperlane messages and convert it into a capability on Kadena’s smart contract. A capability acknowledges that a specific permission has been granted, such as the ability to receive tokens because the verifier plugin confirmed a burn happened on the Hyperlane bridge.

We've recently leveraged this method further by creating a service provider interface (SPI) to allow our partners to provide verifier plugins.

Unique Benefits of ZK on Kadena vs Ethereum

ZK proofs are not an afterthought for us due to verifier plugins, which allow ZKs to fit very naturally into our environment through our work with Lurk.

Similar to Pre-Compile in Ethereum

Ethereum-minded technologists can think of SPIs as a pre-compile. SPIs will allow anyone building on Kadena to leverage a precompile to the system that will take arbitrary data that can be attached to the payload of the transaction and perform any desired verification.

For example, verifying a ZK proof would demonstrate that it is valid. So what does that turn into? It turns into a capability. The Pact code itself does not verify the ZK proof.

ZK Proof Consumption on Pact vs Solidity (Ethereum)

Kadena’s security model for Pact enables the integration of ZKs on our platform without bloating the smart contracts. Consequently, integrating ZKs into Ethereum’s Solidity contracts will only complicate the process of writing smart contracts. This involves learning a new set of verification primitives and calling them within the smart contract, which will incur gas fees, just like any other contract.

More Language Flexibility on Pact

Verifier plugins do not have to be written in Pact like Ethereum smart contracts have to be written in Solidity — ZK contracts on Kadena can be priced differently than a regular transaction. For example, you can provide us with a verifier plugin that is hand-coded in Assembly or that uses a GPU running on the node. These possibilities exist uniquely in our chain.

The Future of Security With ZK

In collaboration with Argument, Kadena’s unique security model and strategic integration of ZK proofs keep crypto out of smart contracts. Smart contracts on Kadena simplify development while enhancing security. Introducing capabilities in Pact allows our smart contracts to operate without direct cryptographic elements, preventing transaction malleability.

Verifier plugins and our service provider interface illustrate Kadena's commitment to innovation and security, ensuring a robust and scalable blockchain environment that adapts to evolving needs. Furthermore, we limit the multi-access point smart contracts (e.g., SCAs in EIP-3074) and instead promote one-time access to smart contracts. Finally, our unique security model allows for language flexibility, so if you want to hand-code a smart contract in Assembly, you can do that on Kadena.