שאלות נפוצות

מה המשימה של זן?

בשביל מה בלוקצ'יין?

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.

איך זן שונה מפלטפורמות חוזים חכמים אחרות?

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.

האם זן סיידצ'יין?

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.

מה הקשר בין זן לביטקוין

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.

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.