Nyzo techNyzoScript

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);

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 NyzoScriptState object, the values it provides for creationHeight, lastUpdate Height, and containsUnconfirmedData are not honored. These values are set by the script manager. The creationHeight is the lowest height that contributed information to the state, the lastUpdateHeight is the greatest height that contributed information to the state thus far, and containsUnconfirmed Data 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 NyzoScripts, 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 between calls to its update() method.