NEP-21: Newton Physical Asset (NPA)

Simple Summary #

Newton Physical Asset (NPA) is the base class of physical asset classes. NPA requires certain proof mechanisms to be included as a part of guarantee to allow transaction of ownership. Two basic types of proof must be made available:

1. Proof of Existence: The asset must provide some mechanism to show the asset exists, such as some online API to show that certain goods or services physically exist, that responded with some provable existence message.
2. Proof of Ownership: This mechanism must provide certain information that shows the goods or services of interest can be traded under Newton accounts.

Besides the notion of Existence and Ownership, physical assets are further divided into two broad categories, often called: Movable/Personal and Immovable/Real Estate Properties. These asset terms are commonly used in legal and accounting practice, and will be adopted by NPA’s namespace management. However, under the accounting classification of Movable Properties, a special category called Intangible Property such as copyrights, brand names, or patents, are not considered a subclass of NPA. Intangible Property is to be classified as subclasses of Named Asset in the inheritance hierarchy of NEAT data types.

Abstract #

Newton Physical Asset (NPA) is the base asset class that uses executable contract to guarantee the existence and ownership rights of physical assets. Knowing that the cybernetic world and the physical world could exist discrepancies, NPA attempts to approximate the existence and ownership proofs using a combination of four things: Proof of Stake, Soundness Analysis, Precision Analysis, and Time-bound Proofs. These four strategies of proving ownership and existence of physical goods provide a negotiation platform for all Newton account owners to engage with transactions. The design and evolution of NPA will follow the concepts originally developed in property law[1], where the basic rights associated with properties are broadly classified as: Rights to possession, use, manage, income generated, capital, and transmissibility. These rights applies to all assets, including non-physical assets. For NPA specific asset classes, Movable and Immovable assets are distinguished. Then, within Movable Assets, Consumable, Durable, and Interest Generating assets are classified. Within Immovable Assets, Owned and Leased Assets are the two main classes. These classifications are designed to offer time-based distinctions of relationships between assets and accounts.

Motivation #

The key idea in NPA is to establish provable relationships between accounts and the physical piece of assets. NPA’s main design motivation is to leverage the cryptographically-protected account system with a trust-worthy timestamp data service and existing proof of stake insurance policies to secure NPA related transactions. In other words, the key idea of NPA is to unify the overarching framework rooted in NEAT. NPA helps to reduce costs of negotiation by introducing automated reasoning mechanisms about the claims of existence and ownership through Soundness Proofs, Precision Assessment[4], and Newton’s secure timestamp system.

Reuse Code by Sharing Expertise across the Supply Chain Management Industry #

Instead of requiring all NPA issuers to learn formal methods and speak in terms of Soundness, Precision, and time security. NPA will work with the standard vocabulary established in the supply chain industry, and primarily focus on proof mechanisms that are related to existence and ownership proofs. By translating the vocabulary from technical domains to supply chain domain, we can separate the work between the two professions. NPA issuers can search for existence and ownership proof in their business specific requirement language, and relevant soundness and precision reasoning mechanisms will be categorized in business terms to help NPA issuers to customize and compose existing executable code to support their needs. Once a new set of executable “smart” contract has been tested and proven to work in the marketplace with live data, the code can be shared to similar business practices across the Newton Community. Therefore, it is crucial to keep an abstract vocabulary to describe NPA, so that code reuse can be maximized.

User Interface for NPA #

When exchanging physical goods, buyers and sellers are likely to perform both sending and receiving roles interchangeably. A reason for the bi-directional sending and receiving functions on both buyer and seller sides is because physical goods might be returned or send back for repair or replacement. Therefore a set of user interfaces that define existence and ownership with precise time bounds on both ends become a significant driver in broadening user base.

The strategy for designing user interface of NPA is to insure that roles of sending and receiving are categorized into a set of functional specifications, so that the “skin” of the user interfaces can be attached to those standardized functional specifications interchangeably. By defining a set of generally applicable functional specifications for delivery and reception verification, NPA will be relatively easy to target many application contexts without having to reinvent the wheels everytime a new, but similar business model is created. This will also help Newton Community to reach a larger community base within a shorter amount of time.

Non-repudiation Features #

Once certain physical goods are delivered or received, it is necessary to make sure that senders and receivers will not repudiate their reception or sending status. To minimize these possible information conflicts, repudiation resolution process should be designed as a measurable cost component, so that anyone who decides to go through a repudiation process, the system will automatically assign risk factors to parties who breached the repudiation contracts.

NPA knowledge as a source of income #

Any vendors or buyers submitting bug reports or prescribe solutions to any of the above mentioned problems, will be automatically given credits or be rewarded of their contribution. The more of their cases being adopted and used as a resolution for future cases, the more credit they will receive. Buying and consuming as actions, will naturally accumulate operational data, and data can provide information and potential wisdom to better refine the overall framework of physical good exchange. An explicit reward mechanism will incentivize participants to actively contribute their intellect to help build up a better NPA transaction rule base.

Specification #

NPA should use NEAT as the basis of transaction model, which implicitly leverages secure timestamping services built-in Newton Infrastructure. Then, all physical goods must work with Newton Asset Namespace (NAM), so that a unifying namespace could be leveraged to reference known types of physical goods.

The existence and ownership status of physical items, should be bounded to existing industry standards or publicly verifiable data sources. Each of these existence and data precision qualities should be bounded to version controlled automatic analytical algorithms that defines the soundness and precision claims. Unless these self-administrating features are provided, no NPA should be issued.

Syntax and Semantics #

The data structure and the meaning of transactional physical items should also be defined using ideas derived from pi-Calculus. This section inherits all features of NEAT, with the additional records that defines existence and ownership statuses.

Interaction / Functions #

Rationale #

The transactions of digitally representable assets can be best illustrated by the four fundamental rights as explained by Richard Stallman’s “Free Software, Free Society”[ available here].

Leveraging the fundamental rights to the four composable rules, one can define a way to cover a wide range of data asset transaction scenarios that have been investigated for decades by prior luminaries, such as Richard Stallman, Robin Milner, and Leslie Lamport.

Backwards Compatibility #

All NEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The NEP must explain how the author proposes to deal with these incompatibilities. NEP submissions without a sufficient backwards compatibility treatise may be rejected outright.

Test Cases #

All test cases of NEAT should be classified into two kinds:

1. Safety tests: examining conditions for when the contract execution will not cause undesirable situations.
2. Liveness tests: examining conditions for when contract execution will ensure something desirable would actually happen.

The safety and liveness tests should be created based on tools such as Static Analysis and TLA+ and other similar test case generation tools.

Test cases for NEAT should first be conducted on dedicated Newton Test Chain, so that the compatibility of the system could be managed between the two systems.

Security Considerations #

Every NEAT type should be a totally isolated container of its own risks. Every subtype of NEAT will define an equivalent class of risk as measured by our Control Plane. Therefore, the assets associated with the NEAT type should be defined as a bounded liability, so that its risk factors are isolated from the other parts of Newton infrastructure.

The Mechanisms of Proofs #

With modern Internet of Things (IoT) Infrastructure, many physical goods and services can attain multi-party, or independent sources of existence proof or ownership proof. Massively manufactured online sensors and actuators usually come with a Media Access Control Address (MAC address), these kind of information can provide the unique identities and locations of information validity. Couple with a distributed timestamp, which will be provided by Newchain, a time-bound security mechanism can be established to validate the proof. In NPA, we suggest the use of static analysis techniques, such as Abstract Interpretation [ 1] to perform Soundness and Precision Analysis. The notion of Soundness and Precision must be interpreted abstractly, meaning that the quality of NPA should be judged by how well the NPA presents “ sound” judgement and “precise” approximation [ 2], as defined in static analysis tools, independent from the concrete execution of product transaction activities. All subclasses of NPA should follow the Soundness and Precision definition presented in this document, so that every NPA’s risk profile can be assessed based on these formally defined characteristics.

Every sub class of NEAT must go through a rigorous process to demonstrate that risks are divided into explicitly defined namespaces. The technical term is called identifying “Behavioral Equivalence”. Assets that can be exchanged through the same kind of transactional mechanisms, should use the same “class” of NEAT contract. The security features of each NEAT contract should be proven through the software development process. Certain anecdotal thinking can be found in Steiner’s blog entry[ 5]. However, to reach a more rigorous level of security, NEAT should try to prove and approve every new subclass following formal methods as described in Rosu’s paper: [6]. Rosu also leads the K Framework development, which is a rewrite-based language design model that can be used to define and verify formal properties of languages, such as security related properties. The working mechanism of proofs are managed in a namespace known as types of NEAT, so that all risk factors can be first reasoned in the categories, or types of risks, before committing to real world applications.

References #

1. Alison Clarke, Paul Kohler, Property Law: Commentary and Materials, Cambridge University Press, 2006

2. Alex Pentland, Alexander Lipton, and Thomas Hardjono, Building the New Economy, MIT Press

3. Patrick Cousot, Abstract Interpretation, Website

4. Bertrand Meyer, Soundness and Completeness: With Precision, Blog@CACM, April 20, 2019, Web, Web

Copyright #

Copyright and related rights waived via CC BY-SA 4.0.