Frequently Asked Questions
What is Zen's mission?
We're building a platform that will let anyone in the world find and use financial products with strong security. We want to open up the ability to create new kinds of assets to a global base of developers and financial engineers.
Why a blockchain?
Smart contracts don’t have to live in decentralized consensus. When Nick Szabo Invented Smart Contracts, he saw them as running in physical devices like cars—that is, smart property—and perhaps on some trusted central notary systems. This original concept has the advantages of being relatively easy to implement, fast, cheap, and fairly easy to understand from an economic perspective.
With the invention of decentralized ledgers, it became possible to take a notary system and “put it on the blockchain”. In this design, the contract is set in stone, but it isn’t enforced by the protocol itself. There are also systems that run centrally, but use digital currency—for example, Open Transactions. In these systems, you trust the operator to do what the protocol says, and if she breaks her word you can prove it in public.
Zen isn’t like any of these, although it can work very well with some of these systems. It takes contracts, puts them into a decentralized ledger, and then automatically resolves those contracts according to their source code. Systems like Zen enable users to trade with anyone else in the world, without needing to find someone whom they both trust. The security is algorithmic.
How is Zen different from other smart contract platforms?
Zen is different economically and technically.
Economically, Zen isn’t in the “digital cash” market. You can use the Zen token as a unit of account, but Zen also works with Bitcoin—moving value on and off the Zen blockchain as required. That’s because we see Zen and Bitcoin as complementary. If Bitcoin enabled contracts of arbitrary complexity, those contracts would consume resources that would otherwise be used to move Bitcoins around more cheaply and quickly. That would make Bitcoin worse at being money, so it’s not likely that bitcoiners will accept such a change. Proposals like Simplicity make Bitcoin contracts more expressive, but they’re designed to strictly limit the computation they use.
Zen Protocol supports more computation in contracts: it makes you prove how much they need, but has much more generous limits on how much is “too much”. Linking to Bitcoin means that it can be more flexible than protocols like Ethereum and Tezos, which try to be money and unlimited smart contract platforms at the same time.
Apart from the economic differences, Zen’s focus on finance and digital agreements has also inspired key design decisions which make Zen technically different. Let’s look at two examples: how Zen manages resource consumption, and how it deals with tokens.
In some ways, platforms like Ethereum aren’t much different from what you might find in an early ‘80s microcomputer. This is a problem if your contract looks like this:
10 PRINT "Hello, World!"
20 GOTO 10
To stop infinite loops, Ethereum uses a “gas” system. Before you run a contract, you must buy “gas” to run it with. Run out of gas and your code throws an error, everything gets “reset”, and you lose whatever you paid for the gas with which you tried to run the contract.
This isn’t a good solution for financial software. People want their transactions either to succeed or to fail cleanly—not to be stuck with the bill for a transaction that their client wasn’t smart enough to price correctly. Zen Protocol’s focus on finance led us to develop smart contracts that work atomically—they don’t cost anything unless they run all the way to the end. We implement them using a new consensus rule: contracts must carry proofs about how long they take to run. This is only possible with an advanced system for formally verifying contracts. It also means that Zen isn’t really like that ‘80s micro—all of Zen’s programs finish running within a reasonable time limit. By the way, this also means we can compile contracts to run at native app speed, instead of “counting gas” in an interpreter or emulator.
As well as the basic smart contract architecture, we recognize that certain functions are very common on a smart contract platform: creating and transferring assets. That’s one reason why Zen has first class tokens—assets that can be held and transferred by users without talking to the contracts that issued them. This is another move away from a pure “world computer”, in the interests of making Zen more usable for financial products. Not only does this make Zen faster, it means that new assets are automatically compatible with any contract that chooses to process them, and that transaction fees can be paid in any token.
Is Zen a sidechain?
It can be! Sidechains need to move value in two directions: from Bitcoin to the sidechain, and back again. Zen enforces one direction of a Bitcoin-to-Zen peg: actions on Bitcoin can have automatic effects in Zen. The other direction is harder! We support all existing solutions to the problem of sidechains, such as federation or personally guaranteed deposits. Additionally, Zen can enforce collateral requirements: Bitcoin gateways can lock assets on Zen that insure against failure to cash users out to the Bitcoin network. Our formal verification support means that the assets these gateways issue can work with other contracts, carrying a quantified amount of risk.
We are also forward compatible with changes to Bitcoin that enable two-way pegs. In fact, the Zen Protocol is flexible enough that most sidechain proposals would work without even needing a soft-fork.
Is Zen a meta-chain?
No. Meta-chains use an existing blockchain, and add a new layer of meaning to some actions in that blockchain. The Zen Protocol is a new blockchain that runs in parallel to Bitcoin. It has its own consensus mechanism, mining incentives, and transaction format.
What connections are there between Zen and Bitcoin?
Zen contracts can listen to events on the Bitcoin network, enabling uses such as automatically selling an asset or a service for Bitcoin payments. The Zen Protocol supports sidechains, in which Bitcoins move between the two chains, through federation, guaranteed deposits, and collateralization, and will integrate with future sidechain proposals for Bitcoin.
What is Merged Consensus?
Merged consensus is how the Zen Protocol stays up to date with what’s happening on Bitcoin. Miners add Bitcoin block headers to Zen, then everyone—miners and nodes—agrees on which headers are in the Bitcoin chain with the most work. There’s a grace period to download and check the Bitcoin blocks, so small reorganizations of the Bitcoin blockchain don’t cause reorgs on Zen. Rather than using a custom Bitcoin client, a Zen Protocol node will get data from a standard Bitcoin node via RPC.
What is multi-hash mining?
Multi-hash mining is our solution for aligning incentives between miners and users of the Zen Protocol. For each block, a miner can choose between one of several hash functions to use, each with its own difficulty. The Protocol has a target ratio between the blocks mined using these functions. If too many blocks are mined using a particular function, then its difficulty increases, reducing the efficiency of mining with that function. Token holders vote to adjust the target ratio, providing feedback on how they want the blockchain to be secured.
This gives miners the strong incentive to do what token holders want, because switching between different hash functions is usually quite expensive for the miner, particularly when using specialized hardware. On the other hand, token holders have no incentive to change the target ratio, provided miners are acting in their interests and the blockchain is being secured.
What is the active contract set?
The active contract set (ACS) contains all the contracts which can directly affect the network. The Zen Protocol reduces network load by allowing contracts to leave the set when they are not needed, while still allowing the tokens they generate to move freely.
What is the contract sacrifice?
The contract sacrifice is a special fee, paid in the native Zen token, that activates a contract, enabling it to process transactions. The sacrifice is divided between all the miners who find blocks while the contract remains active, compensating them for the cost of keeping the contract in memory, ready to run whenever they need to validate a contract-generated transaction.
Is there a coin?
There is. Zen has a native scarce token, used to create contracts, but not needed to use them. The decision to have such a token comes from the need for a focal point for miners—an asset that all miners wish to receive. Without such a token, there is no way to guarantee the incentives of miners to secure the network with their hashpower. We avoid having the native token compete to be “better money” by making it mandatory only for the actions which represent the Zen Protocol’s added value—making smart contracts.