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
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.
Graffiti scriptNickname script