The MetaCert Protocol Technical Paper: System Architecture
This section covers the system architecture, and the numerous Protocol services.
Contents
Clicking on each heading will take you that section’s medium post.
3. System Architecture
6. Decentralized Technical Governance
System Architecture
In the system architecture, the blockchain occupies the secure base layer to document consensus on data bindings of the state of digital assets (e.g domain verification or URI classification). We chose to follow a design principle to keep as much complexity and logic outside of the blockchain layer as possible.
Think of the system as clusters of high speed virtualization sync Nodes wrapped around existing blockchain capabilities to enable real-time transactions at the participant level, just like virtual machines are constructed on top of physical hardware in traditional Software as a Service (SaaS) models.
The primary benefit of our virtual sync Node implementation is better fault tolerance in case of a failure of the underlying blockchain.
Protocol Services
Architecturally, all services are built independently of each other, which increases the stability of the entire Protocol. The disruption of one service will not cause the failure of the another or the system at large.
All components of the platform interact with each other via a RESTful API, specially designed to provide data exchange between the internal and external services of the system.
Synchronization Service
The Protocol uses the HyperChain, a service that interacts with the blockchain and the ChainKit platform, functioning as a high-speed sync of the blockchain’s ledger. Thanks to this service architecture, even its complete disconnection will not affect data continuity and safety.
Consumers of Sync Service:
- MetaCert (Super Consumer) : Unrestricted, uninterrupted, unthrottled access Service.
- Enterprise Consumer: Predefined or Prearranged, throttled access.
- Generic Consumer: Limited access granted to developers and entities seeking to build applications around the Protocol. Restriction level may be flexible based on usage.
API Service
The API service is an essential component of the ChainKit, which will operate independently and allow access not only at the transactional level but as well as the data level. This in turn empowers developers and any entities interested in the implementation of distributed ledger technology. The API will have features such as an unconfirmed transaction confidence factor, dependable WebHook or WebSockets-based events, on-chain microtransactions, and a query for ledger event metadata.
The API can be integrated into popular applications (Slack, Firefox, Chrome) and be used to build your own tools and services.
Submission Service
Submission Flow
A Submitter must first be authenticated with a participant account before being able to submit a URI. The submission flow will vary depending on the Submitter class defined below. The standard Submitter class submission flow is:
- Submitter enters or pastes URI for classification.
- Selects one or more classifications to attribute to the URI.
- Chooses if the classifications should apply to:
○ the entire domain.
○ the current URI directory (folder) and below.
○ the specific URI only. - Some classifications, such as ownership verification may require Token charges while other URI classifications require Token to be staked in order to submit.
- Token charge or staking fee for submitting a URI is displayed on the submission page.
- Submitter pays and receives notification of Token charge if required.
- Confirmation view displays estimated time for verification based on current backlog.
- When verification is completed, a notification is sent to the Submitter via their chosen channel of communication set in their profile settings.
Submitter Classes
Based on the Submitter class, a different submission and validation flow will be adopted. The Protocol will initially cater to the following Submitter classes:
- GTLD Registrar: Domain registrar, that wishes to bulk submit current or future domains for classification. It is not necessary that these domains contain any content.
- Expert: Industry experts, who are well known for their knowledge and expertise in one or more categorization types.
- Domain Owner: Domain/Site owners who wish to claim their domain classification.
- Standard: General community Submitters.
- Pro: A general Submitter that has achieved high enough reputation and has concurrent submission limitation increased.
Submission Status
Based on Submitter Class and category, submissions in the Protocol will be associated with one of the following statuses:
- Accepted: When a URI submission is accepted, but is not in review.
- Rejected: When a URI submission is rejected and tagged with a rejection reason.
- In Review: When a URI submission is Accepted and available for review by a Validator.
- Pending: When a URI submission is accepted but the DNS does not yet resolve.
- Claimed: When a domain URI for ownership is validated (note: this status has an expiry date).
- Expired: When a domain URI that has been validated for ownership reaches its expiry date.
- Validated: When a URI submission is reviewed and validated by 1 or more Validator.
- Disputed: When the combination of a URI and classification is in the process of being challenged by a participant, this status remains until a resolution is reached.
Submission Acceptance
Submission acceptance will occur following predefined, automated acceptance checks:
- DNS resolves correctly (For Domains)
- Domain Control Validation (For Domain Owner Claim)
- Reverse Proxy Validation (For URI Submissions)
- TLD/GTLD Validation (For XXX Category Submissions)
- Metadata Crawling (For XXX Category Submissions)
- URL Resolve Validation (For All URIs)
Ledger Service
The Protocol’s Ledger Service is more than a shared, immutable ledger for recording the history of transactions. It provides a permissioned network with known identities. Transparent and highly available, the Ledger Service is designed to record all events, from the request of a URI submission to a participants reputation, since events are cryptographically linked to one another via timestamps and other attributes.
The Ledger Service will allow URI submissions, validations, disputes, participant reputations, and Token transactions that are open, transparent, and verifiable.
Authenticity Service
The Protocol’s authenticity service acts as gatekeeper, to other microservices. The primary function of this service is to provide a boolean response plus timestamp of a queried event for other microservices that need confirmation of a classification for a URI.
The service will provide responses for events such as Ledger service encryption and security, transaction authenticity validation, user identification and more.
This service will employ industry standard encryption to secure transactions to and from this service module.
Reputation Service
The reputation service is designed to calculate ratings for all participants (Validators, Submitters, disputers and End Users). The rating algorithm is based on multiple key metrics that dictate user reputations and credibility scores, which include:
- Positive Metrics:
○ Account Age
○ Positive acknowledgement by other participants weighted by their reputation rating
○ Number of followers within the Protocol
○ Number of successful transactions (- Submissions/Validations)
○ Number of votes cast on the winning side of a dispute resolution. - Negative Metrics:
○ Negative acknowledgement by other participants weighted by their reputation rating.
○ Number of unsuccessful submissions
○ Number of non-concurred validation judgements
○ Number of votes on the losing side of dispute resolution - Ordained Metrics:
○ Granted to existing industry experts that fulfill registration criteria issued by the Protocol
The entire reputation system is governed by a core base rule, which cannot be modified by any Node. However, an extended rule can be incorporated onto the base rule with a certain degree of limitation on a Node level. Each reputation gain and loss is written to the blockchain, thus making the entire reputation ledger decentralized, i.e. reputation data resides on chain, however additional data from extended rules will always be held off chain for use within the Node only.
ChainKit Services
To manage Submissions, Validations, and Update Nodes, developers will have access to all the necessary tools for the ChainKit in the form of API documentation, Software Development Kits (SDKs) for popular platforms, and software suites.
SDK Services will help developers make their app integration process as smooth as possible, allowing them to flexibly adopt Protocol events into their workflows for submissions, validations, and data consumption.
Additional Microservices
A large number of additional services will be implemented on the Protocol’s Nodes. Of note, the development of submission management using Artificial Intelligence (“AI”), which will use Big Data analysis modules and an algorithm to collate additional information after submissions. This will provide an opportunity to automate filtering of unresolving or restricted access URI submissions in the system.
Another example would be for the AI to obtain analytical data on the queries on the leger to monitor the frequency of use for each URI on the Protocol to determine popularity.
Contents
Clicking on each heading will take you that section’s medium post.
3. System Architecture
🖌 Please feel free to respond with questions or comments about anything you read in our White Paper or Technical Paper directly within Medium, and be sure to engage with other members of the community who also have questions or comments.
🔐 MetaCert Protocol is based on established enterprise-grade technology that powers live products. These products protect hundreds of thousands of people on the Internet today, but this is just the start. We need the community to help us iterate this work. Together we can help make the Internet a safer place for everyone.
☞ Don’t forget to click 👏🏻 to let MetaCert and others know how much you appreciate this post.
☞ Install Cryptonite to help protect your crypto from phishing scams. https://metacertprotocol.com/cryptonite
☞ Use our Telegram Security Bot to check the status of links and crypto addresses, and warn users about phishing in Telegram communities. https://metacertprotocol.com/telegram-bot
☞ Join our Telegram channel where you can engage with the core team and the community. https://t.me/metacert
