2. Key Concepts

2.1 AMB-NET Data Overview

By default, all data created on or uploaded to AMB-NET is private, as most enterprise data needs to be concealed, due to regulations, contractual agreements and trade-secret protection. All AMB-NET data is stored off-chain and covered only by a guarantee limited to tamper-proofing. The sole Owner of private data is responsible for preventing its loss and/or contamination.

However, data leaves a signature on the AMB-NET blockchain in the form of a hash function — an alphanumeric character string that corresponds to the data entry that was created/uploaded. The hash signature will never reveal any of the content of uploaded entries, rendering it impossible to decrypt or reconstruct private data. Instead, these hash marks preserve metadata in the form of Asset ID, Event ID, author, timestamp, and certain access-control conditions.

Functioning as a serial number or an identification code, this hash mark helps public counterparties, trade partners and regulators cross-reference published data with hash metadata, revealing the time, date and author stamp for the creation of AMB-NET data.

AMB-NET’s intelligent design ensures that data, once published and stored, cannot be modified without an accompanying audit trail, documenting the journey of the bundle or hash sequence.

2.2 AMB-NET Data Types

AMB-NET was designed to process three types of data:

Private: Material non-public information or other protected data that is created and stored by a client for internal use only. Outside of the data producer, no entity can view these records, as they are securely siloed within the producer’s internal databases. Example: The price a company paid for a delivery of tomatoes.

Material non-public information or other protected data that is created and stored by a client for internal use only. Outside of the data producer, no entity can view these records, as they are securely siloed within the producer’s internal databases. Example: The price a company paid for a delivery of tomatoes. Shared: Private data that has been shared explicitly with one or several other peers. Only designated peers with valid authentication tokens are able to access this data. Example: The full history of shipment #223, sent by company Alpha to corporation Beta.

Private data that has been shared explicitly with one or several other peers. Only designated peers with valid authentication tokens are able to access this data. Example: The full history of shipment #223, sent by company Alpha to corporation Beta. Public: Private data that has been openly shared with every user on the AMB-NET network. Example: the ingredients list and expiration date on a yoghurt pack.

All AMB-NET data is logged as an “event stream” and classified by two core entity types:

Assets : Models a physical or logical entity and represents a single stream of Events.

: Models a physical or logical entity and represents a single stream of Events. Events: Captures all the supply chain data collected for one or multiple Assets

Example of Assets and Events for a product travelling through the supply chain powered by Ambrosus

2.3 Receipt

To mitigate data-tampering risks, AMB-NET uses a PoA blockchain protocol that generates and stores a cryptographic proof of content at upload time. Due to proliferating Asset and Event entry volumes, it’s impractical to store a separate proof for each entry. Instead, these entries are grouped together into Bundles. A proof (in the form of a hash) of these Bundles is then stored on the blockchain alongside a minimal set of metadata. The actual content is stored on Hermes and Atlas Masternodes, where it can be later retrieved using traditional database technologies.

Bundles only hold full entries for public data. Private data is always represented by hash entries, which only reveal metadata about Assets and Events.

2.4 Expiration

All public AMB-NET data has a pre-defined storage life, with download availability expiring when the storage period ends. This expiration date mechanism can help enterprises comply with regulatory recordkeeping requirements, while mitigating AMB-NET congestion and data decay, when records become irrelevant. Data cleansing at regular specified intervals, ensures AMB-NET’s continuously high-transaction throughput and ledger operability.

AMB-NET enables clients to purge public and private data from their nodes once it has decayed beyond the point of compliance, regulatory or other recall utilities. Data lifespan can be defined at upload, with varying AMB-NET fee schedules determined by the storage needs of the client.

The holding time is specified during Bundle upload and published in the Receipt. It needs to be expressed in multiples of 365 days, with the minimal storage period being 365 days. There is no upper limit to data storage life. Ambrosus empowers its network to independently make those decisions.

AMB-NET’s discretionary data-cleansing feature is a key cryptoeconomic differentiator that ensures continuous operability and efficient transaction throughput for network participants. In this context, AMB-NET users are incentivized to implement data management best practices to promote a better network experience for themselves and the community.

2.5 Data Sheltering

Certain AMB-NET Masternodes will assume Data Sheltering responsibilities for the storage of client data until its expiration date. AMB-NET generally delegates this capability to Hermes Nodes, which produce data, and Atlas Nodes, which resolve Challenges and store data in exchange for AMB token rewards. But storage duties can also be determined by other network interactions and transactions.

2.6 Storage Fee

At the data-upload stage, users must pay a Storage Fee in addition to standard network transaction fees. Storage Fees are used to cover the costs of operating the network and redistributed to support various incentive schemes that reward designated Masternodes for storing or backing up data throughout its information lifecycle. All fees are paid in AMB tokens.

2.7 Nectar

AMB-NET prices AMB transactions in terms of Nectar, a specialized unit that measures the computational intensity of various actions on the network, and on a floating scale, akin to the concept of Gas in Ethereum. Thus, Nectar costs rise as data transactions become larger or more complex. In certain market environments, Nectar’s floating rate can also reinforce AMB-NET price stability, ensuring that Storage and Transaction Fees never become unreasonable or hinder the industrial adoption of AMB-NET. Thus, Nectar and Amber have a dynamic relationship to facilitate harmonic interaction between different stakeholders of AMB-NET.

2.8 Stake

Some AMB-NET users are required to deposit a specified amount of Amber to deter them from behaving in a way that disrupts or impairs the AMB-NET network. When this stake falls below a threshold value, the user loses the right to perform some network functions. The missing AMB needs to be replenished before the user can resume full participation on AMB-NET.

2.9 Penalties

Acting in a way that impairs the proper functioning of AMB-NET results in an AMB penalty for offending users. As it is not always possible to determine if misconduct was intentional, or the result of technical issues, penalties increases with each succeeding offence.

2.9a Storage Challenge

Any user who has assumed Data Sheltering duties can be Challenged by other users to reveal the records they claim to possess. This places the burden of proof on the Shelterer to respond to the challenge with the data being queried. The resolution of each Challenge is handled by an independent and staked Atlas Masternode.

When the Challenge is resolved, the Atlas Masternode that processed the query also becomes a Shelterer of challenged data, multiplying data resilience throughout the AMB-NET network. Failing to respond to a Challenge request results in a monetary penalty, which promotes persistent node engagement with and connectivity to AMB-NET.

2.9b Data Resilience

Data resilience is a key component of AMB-NET’s cryptoeconomic model. The outcome of a successfully resolved Challenge Request, data resilience is the duplication of records across another or various other nodes. AMB-NET incentivises other Masternode participants to copy and shelter this data, as a loss-prevention mechanism to reinforce the continuous discoverability of network Assets and Events.

2.9c Challenge Fee

Initiating a Storage Challenge requires the user to pay a fee in AMB. This Challenge Fee is used to cover the cost of resolving the Challenge and the resulting storage of the duplicate data. Fee-pricing is calculated proportionally to the holding period of challenged data.

2.9d Data Storage Transfer

A Data Shelterer can request that their storage contract be transferred to a different user. The recipient volunteers to shelter the data and, in return, receives a Transfer Fee paid by the requester. This Transfer Fee is priced as proportion of the initial Storage Fee, relative to the remaining storage life of the data, with a small premium included over the base amount.