OriginTrail
Published in

OriginTrail

OT-RFC-14 DKG v6 TRAC Tokenomics

From data to assets — gateway to the knowledge economy

  • The DKG layer hosts the asset graph state (1) in semantic form (RDF), identified by a new Web3 primitive — the Uniform Asset Locator (UAL) (2). Similar to how Uniform Resource Locators (URLs) made it possible to reference an object (e.g. a website or document) in Web2, UALs make it possible to reference anything physical or digital, in Web3. UALs extend existing web URI standards, revolutionizing URLs as their counterparts in Web2. A UAL also inherits capabilities described in the W3C recommendation on Decentralized Identifiers (DIDs). The UAL format (to be formally specified in further documents) therefore is in the following standardized form:

    dkg: [// DID] / UAI [“?” query] [“#” fragment]
  • The Blockchain layer is responsible for maintaining asset ownership record and asset graph state verifiability proofs. Information about ownership is kept in the form of an ERC 721 compatible Non Fungible Token (3). This allows us to tie DKG and blockchain layers even more closely together and enable ownership to be transferable in the form of NFT token transfer. State commit proofs (4) are used to verify that the asset graphs DKG nodes persist are available, haven’t been deleted or in any form tampered with, as well as enabling complex verifiable presentation implementations (according to W3C Verifiable Credentials).

Moving from data bundles to unique assets

DKG as a Multi-chain Decentralized Knowledge Graph

Guidelines to TRAC tokenomics

  • Ease of use — asset publishers are the core users of the OriginTrail DKG and in order to allow them to engage with OriginTrail technology, it should be reasonably easy to use.
  • Cost efficiency — allow the market to achieve attractive prices by not wasting resources.
  • DKG node rewards — allow DKG nodes to get compensated for providing useful services to the network. By enabling an efficient market for the “supply side” of the DKG network, infrastructure runners can get fairly compensated.
  • Quality of service — ensure that applications querying the DKG (asset consumers) benefit from a high quality service.
  • Scalability of network activity — implement a system that has capacity to support the rising levels of adoption.
  • Decentralization — as a core consideration in any implementation and tokenomics decision, avoiding system control by any single party.

TRAC tokenomics stakeholders

  1. DKG asset publishers are agents which create and manage knowledge graph entities (assets) by publishing asset graphs to the DKG according to the OriginTrail Protocol
  2. DKG asset consumers are agents who discover, query and consume the DKG asset graphs created and owned by DKG asset publishers
  3. DKG node runners, who run and maintain the DKG infrastructure nodes, providing the DKG services
  4. TRAC Token holders, who participate in the ecosystem by providing economic support for system activities

DKG node services

  • Publishing protocols, which introduce additional asset graphs into the DKG (equivalent to semantic web publishing, or a database insert operations)
  • Querying protocols, which enable asset discovery through network queries (equivalent to database query operations)
  • full or service nodes which provide network services implementing full DKG protocol choreographies. Full nodes persist the public DKG state, make it available and execute semantic queries, in return for getting compensated in TRAC tokens.
  • light nodes which do not provide network services, rather act as network gateways. They are not responsible for persisting the public DKG state as they do not have such capability (don’t respond to publish requests, therefore don’t qualify for rewards). Light nodes are analogous to the notion of light clients in blockchain networks, eliminating the need for gateways such as RPC services with having direct access to the DKG .

Publishing protocol choreography

  1. Preparation phase: the asset publisher prepares an assertion in the format expected by the protocol
  2. Feature phase: initiates the appropriate functionality of the desired feature (e.g. updating an asset state) on the blockchain
  3. Store phase: invokes the store protocol to create an assertion replica on the DKG
  4. Commit phase: used to finalize the choreography and initiate the service period

Service market mechanics

  1. Key-space proximity criteria: assertions need to be replicated to nodes and maintained in a specific “neighborhood” of the DKG index space, specifically around the key where an assertion is to be kept. Nodes form neighborhoods based on the XOR distance of the assertion key to the node IDs, similar to how distance is determined in Kademlia DHT. This criteria needs to satisfy efficient data discovery in the decentralized network environment by deterministically locating assertion replicas in querying choreographies. Additionally, due to assertion keys being consistently hashed, assertion replicas are evenly and randomly distributed across the network key-space. A neighborhood is formed by the R2 number of nodes (neighborhood size) which is a protocol parameter.
  2. Node compensation asks: once the appropriate neighborhood is determined (satisfying the first criterion), the second requirement is to ensure that there are enough nodes willing to provide the service in that neighborhood, indicated by their compensation ask. A bid satisfying a minimum number of R1 nodes (R1 being the minimum set of “willing” nodes within an R2 neighborhood, R1 <= R2) is considered a valid bid in terms of the second criterion, where R1 is a protocol parameter.
  3. Security signal criterion: after both previous criteria have been satisfied, finally R0 nodes get chosen (R0 being the minimum replication factor) out of the R1 set, based on the amount of provided TRAC token stake. A higher stake of TRAC tokens in the system indicates higher quality of service guarantees by nodes, as the stake represents a collateral guarantee for nodes providing expected services and acting according to service agreements.

Service period

Querying protocol choreography

  1. Preparation phase: the asset consumer client prepares a query in some way (e.g. taking input from a search box)
  2. Feature phase: initiates the query prepared in the previous phase on the DKG, on the appropriate DKG shard, and performs necessary URI resolution if needed
  3. Verification phase: verifies the obtained results from the feature phase using on-chain verifiability proofs (verifying immutability, state consistency, issuer or other)
  4. Presentation phase: presenting the query result to the client in requested form

DKG Node service market

Tokenomics role in system security

OriginTrail v6 scalability considerations

Conclusion

References

  1. OriginTrail Whitepaper
  2. Semantic Web (Wikipedia)
  3. W3C Resource Description Framework
  4. RDF Dataset Canonicalization and Hash Working Group Charter
  5. Kademlia: A Peer-to-peer Information System Based on the XOR Metric
  6. Polkadot Wiki
  7. W3C Decentralized Identifiers
  8. W3C Verifiable Credentials Data Model
  9. OT-RFC-13 TRAC Token Deployment on Polkadot
  10. OT-RFC-12 OriginTrail Parachain TRAC bridges (v2)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store