4.6 Attachments and contract bytecode

Transactions can have several attachments, identified by file hashes. New attachments that have not appeared before are stored and transmitted independently of the transaction data and can only be obtained through the standard parsing stream. Attachments consist of a series of zip files that cannot be individually referenced by contract code. The files in the zip package are collapsed into a single logical file system, with duplicate files only parsed the first time they are mentioned. This approach mirrors the mechanism used by Java class paths.

In DeFi Mall, smart contracts are defined using JVM bytecode as stipulated by The Java Virtual Machine Specification SE 8 Edition. A contract is simply a class that implements the Contract interface, which in turn exposes a single verify function. The verify function takes a transaction as input, throws an exception if the transaction is considered invalid, and returns without any result otherwise. The set of verify functions used is the union of the contracts specified by each state.

Embedding the Java specification in the DeFi Mall framework allows developers to write code in various languages, use well-developed toolchains, and reuse code written in Java and other JVM-compatible languages. Java's standard provides a comprehensive type system for representing generic business data: time and calendar handling through an implementation of JSR310, decimal computation using either portable floating-point algorithms or provided bignum libraries, etc. These libraries, meticulously designed over the years by the commercial Java community, are significantly beneficial when their functionality is based on this resource.

Contract bytecode can also define its own state as any object graph. Since JVM classes are not a convenient form for collaboration from non-JVM platforms, the types that can be used are restricted, and a standardized binary encoding scheme is provided.

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

Attachments may also contain data files provided to contract code. These files and bytecode files can be in the same zip package or another zip package that must be provided with the transaction to be verified. Examples of such data files include currency type definitions, timezone data, and public holiday calendars. Any public information can be referenced in this way. Attachments are specifically designed for data that will be repeatedly used by many participants on the ledger. Data files are accessed by contract code through APIs, the same APIs used for accessing files on the classpath. The platform imposes strict constraints on the types and sizes of data that can be included in attachments to prevent the placement of inappropriate files (videos, PPTs, etc.) on the global ledger.

Note that the transaction creator selects the files to attach. Therefore, it is typical for states to set limits on the data they are willing to accept. Attachments provide data but do not validate it, so a constraint mechanism is needed to prevent exploitation through the provision of malicious data for economic gain.

This is rooted in the contract constraints encoded within the state itself: a state should not only specify a class that implements the Contract interface but also set constraints on the zip/jar files provided to it. These constraints can, in turn, be used to ensure that the contract checks 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.