Supplementary Files and the Compiled Contract Program Code

Transactions can include multiple attachments, which are identified by their file hashes. New attachments that have not been seen before are stored and sent independently from the transaction data. They can only be obtained through the standard parsing stream. Attachments are comprised of a series of zip files, and contract code cannot reference individual files within them. Instead, the files in the zip package are combined into a single logical file system. Duplicate files are only processed the first time they are mentioned, following a similar mechanism as Java class paths.

In DigiNetGuard, smart contracts are defined using JVM bytecode in accordance with The Java Virtual Machine Specification SE 8 Edition. A contract is essentially a class that implements the Contract interface, which exposes a single verify function. This function takes a transaction as input, throws an exception if the transaction is considered invalid, and proceeds without any issues otherwise. The set of verify functions used comprises the contracts specified by each state.

By embedding the Java specification into the DigiNetGuard framework, developers have the flexibility to write code in various languages, utilize well-established toolchains, and leverage existing Java and other JVM-compatible code. Java's standard library offers a comprehensive type system for representing generic business data, including time and calendar handling through JSR310, decimal computation using portable floating-point algorithms or provided bignum libraries, and more. These libraries, refined over the years by the commercial Java community, are highly valuable resources when their functionality is required.

Contract bytecode can define its own state as an object graph. Since JVM classes are not the most convenient form for collaboration across non-JVM platforms, the permissible types are restricted, and a standardized binary encoding scheme is provided.

States can be tagged with a limited set of standardized annotations to control their serialization into JSON and XML (using JSR367 and JSR222, respectively), express static validation constraints (JSR349), and determine how states are inserted into relational databases (JSR338).

Attachments may also contain data files that are provided to contract code. These files and bytecode files can be in the same zip package or another zip package that must be provided along with the transaction for verification. Examples of such data files include currency type definitions, timezone data, and public holiday calendars. Any publicly accessible information can be referenced in this manner. Attachments are specifically designed for data that will be frequently used by many participants on the ledger. Contract code accesses data files through APIs, the same APIs used for accessing files on the classpath. The platform enforces strict constraints on the types and sizes of data that can be included in attachments to prevent the inclusion of inappropriate files (such as videos or presentations) on the global ledger.

It's important to note that the transaction creator selects the files to attach. Therefore, it is common for states to establish limits on the data they are willing to accept. Attachments provide data but do not validate it, so a constraint mechanism is necessary to prevent exploitation through the inclusion of malicious data for financial gain.

This constraint mechanism is rooted in the contract constraints defined within the state itself. A state should not only specify a class that implements the Contract interface but also define constraints on the zip/jar files provided to it. These constraints can, in turn, be used to ensure that the contract verifies the reliability of the data—either by directly checking the data's hash or requiring the data to be signed by a trusted third party.