NyzoScript

This section includes information about the NyzoScript system that is being developed for the Nyzo client. The initial implementation of this was released in version 631 of the Java codebase. This system will provide Turing-complete computation that can be registered on and verified by the Nyzo blockchain.

The initial implementation of NyzoScript was developed to provide server-side functionality for the Micropay graffiti example.

A NyzoScript can be described as a Java interface with the following method signature:

NyzoScriptState update(NyzoScriptState inputState, List<Transaction> transactions);

The following parameters are planned for inclusion in this interface:

• current cycle — to support decentralized cycle governance
• fast-response random value — a pseudorandom value produced by a trusted client
• cycle hash — the cycle hash of the block in which the transactions are contained

A NyzoScriptState is composed of the following fields:

private final long creationHeight;
private final long lastUpdateHeight;
private final byte contentType;
private final boolean containsUnconfirmedData;
private final byte[] data;

Even though a NyzoScript returns a full NyzoScript State object, the values it provides for creationHeight, lastUpdateHeight, and containsUnconfirmed Data are not honored. These values are set by the script manager. The creation Height is the lowest height that contributed information to the state, the last UpdateHeight is the greatest height that contributed information to the state thus far, and containsUnconfirmedData indicates that the state includes data contributed by transactions that have not yet been verified by the cycle.

Each account can have only one NyzoScript registered at one time, and the height at which a script is registered is the height at which it becomes active. However, logic internal to a script can allow it to be registered before it begins processing transactions.

When a new NyzoScript is registered on an account, it fully replaces the previous script, but the state is carried over. However, as with all other behaviors of Nyzo Scripts, the internal logic can choose to process the input state however it chooses.

NyzoScripts will be Turing-complete, but they will not be allowed to access a number of functionalities. Networking will be inaccessible, as will typical sources of pseudorandomness and the system clock. The block manager will be inaccessible. The system will be designed to ensure that NyzoScripts, when they do not contain unconfirmed data, will be fully deterministic based on information that is on the blockchain.

When a NyzoScript does contain unconfirmed data, it will produce exactly the same output state that it would if the transactions had been confirmed. Without access to the frozen edge or the system clock, the NyzoScript will be unable to know whether a transaction is confirmed or unconfirmed, and no metadata will be passed with the transaction to indicate confirmed status. The script will also be disallowed from persisting data outside its NyzoScriptState between calls to its update() method.