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
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.