The MetaCert Protocol Technical Paper: Introduction
This section covers technologies employed, the system, and a high level ecosystem overview.
This document contains technical specifications for the MetaCert Protocol.
By providing a version of our technical paper on Medium, we aim to achieve two things;
- Community engagement — please comment and question any section. If you find that your question or concern is answered elsewhere, please feel free to delete your comment so we don’t end up with more work than is necessary.
- Accessibility — we don’t like reading PDFs but they’re a necessary evil in the crypto world. They’re expected. But we believe medium posts are more accessible across every device — including mobile.
Contents
Clicking on each heading will take you that section’s medium post.
1. Index
2. Introduction
6. Decentralized Technical Governance
Introduction:
The MetaCert Protocol
The MetaCert Protocol (“Protocol”) will be an open security protocol for the Internet storing trust and reputation information about Uniform Resource Identifiers (URIs) which includes domain names, applications, bots, crypto wallet addresses, Application Programming Interfaces (APIs), and content classification. The Protocol’s registry is machine-readable and queryable for use by Internet Service Providers (ISPs), routers, crypto exchanges, Wi-Fi hotspots, mobile devices, browsers, websites, and applications to help address cyber threats such as phishing, malware, brand protection, child safety, and news credibility.
This document outlines the technical specifications around the components that will make up the Protocol. From the technology, usage of the META Token (the “Token”) and system architecture to the Protocol services and the processes that govern the system, each facet of the Protocol plays an important role in ensuring the stability and harmony between the network and the various participants that interact with it.
Technologies
The MetaCert Protocol (“Protocol”) decentralized URI (Uniform Resource Identifier) classification registry will be built primarily using Node.js and Python with the following beneficial characteristics:
- High-speed response. The system will be able to process queries up to 2,500 transactions per second via a sync layer. This enables the platform to ensure real-time transaction processing speeds.
- Elasticity. Blockchain technology ensures continued operation even if up to one-third of the Nodes in the blockchain network are disabled.
- Improved security. Python was chosen because it is designed without segmentation faults which guarantees thread safety. By doing this, we ensure all thread processes occur on the platform in a robust manner.
The System
The Protocol is divided into three independent parts:
1. An End User participant system (codename: ChainKit) using Python, Node.js, and Elasticsearch providing a user interface for parties to validate, submit, and dispute URI classifications. These parties are participants in the Protocol and they include the following user classes: Submitters, Validators, Purchasers, and End Users. The participant system provides, authentication and profile management including (but not limited to) surfacing publicly available immutable metrics generated by the Protocol, such as reputation rating, token metrics and submission or validation statistics.
2. A decentralized blockchain registry that is an independent, distributed storage system for all ledger transactions relating to URIs held within it that are governed by participant Token transactions using smart contracts.
Ethereum smart contracts will be used to enable the management of required entry conditions, digital ledgers, and token mechanics. The smart contract is an independent intermediary between two parties (for example between the Submitter and Validator of the same URI classification submission). All actions processed through a smart contract require an agreement with a digital fingerprint from both parties who wish to participate in each transaction.
The Protocol implements the following key functions through smart contracts:
- Control of an “event ledger” recording all actions (based on HASH) that will be accessible to all Nodes on the network.
- Control of a URI’s “status” recording submissions, validations, and disputes of URI classification submissions.
- Control of “attributes” relating to token credit or debit for participants.
- Control of “metrics” relating to participant reputation.
A smart contract is constructed after successful validation of a submission. After a parameterized waiting period without a dispute being raised against the validation, a token payment allocation is distributed to users involved in Protocol participation
In the event of a dispute of a URI classification, an auxiliary smart contract is initiated between the disputer and the Validator(s) that requires token participation to execute. This ensures the system remains open for critical review while discouraging objections from bad actors.
3. A synchronization system(codename: “HyperChain”) using Python, Node.js and Elasticsearch that provides a layer between the blockchain registry and the ChainKit. This system is responsible for interacting with the blockchain to eliminate latency issues with write transactions. To ensure high performance, we have chosen to architect microservices (described later) utilizing a RESTful API, auto scaling and multi availability zone clusters.
Types of Data
There are three primary types of data across the system network:
- Proprietary Data: This is data controlled by a Node Operator and is generally unique to that Operator.
Example: If Cisco wanted to ensure their Submitters and Validators on their Node were registered Cisco users. - Regulated Data: This is data where accessibility is limited generally due to privacy constraints. This data may not be unique and Nodes may choose if it is shared between them.
Example: The participant age verification for Validators classifying pornography URIs, DNS records or DNSSEC Records. - Common Data: This is data that is open for general use on the blockchain. This type of data has no restrictions on its usage.
Example: Transparent event information showing who submitted, validated or disputed any URI classification submission along with all the URI’s ledger history showing reputations of all participants involved in each event.
High level Ecosystem Overview
The decentralized architecture of the Protocol is designed to allow for specific rules to be applied to URI classification types.
For example, imagine the need for different parameterized rules to be applied to phishing classification compared to pornography classification. Any Node operator can add a Classification type of URI at a Node level when using the Regulated or Common data type as described in Data Types section above.
Each process has two common components. We’ll call them (1) base components and (2) extended components.
Base components are standard rules, processes and data points which can not be altered or overwritten. Think of these as laws common to all Nodes.
Extended components are additional data points on top of base components that Node operators may choose to add and are always specific to those Nodes. Think of these as optional bylaws for each Node.
Each event requires an encrypted code and a signature to verify each Protocol participant, which then forms a unique transaction ID(also known as a universally identifier or UUID).
Each unique transaction enters the blockchain via the HyperChain and the Protocol is able to present a record of the current submission queue in order to process it in real-time. This is because blockchain technology usually takes time to verify each transaction written to it. The blockchain is reevaluated every 2,016 blocks, which is why the process takes time. For the Protocol we need a speedier presentation of activity hence the production of the HyperChain layer to provide this service, which is especially important for real-time sensitive classifications such as phishing.
Each transaction on the Protocol’s decentralized blockchain registry will always be public and verified to avoid problems of authenticity and duplication. Protocol Nodes are responsible for verifying the authenticity of each transaction that includes information such as a new or disputed URI submission, their resulting validations and the reputation of participants.
The Protocol is designed to prevent bad actors from gaming the system by having a waiting period called the challenge period which must expire without a dispute being made against the validation of a submission. This process is built-in before Token amounts are paid out to participants for URI classification transactions.
To prevent bad actors from disrupting the Protocol, participants have a maximum of 5 active new submissions in the challenge period at any given time unless their protocol reputation status permits this limit to be removed.
Contents
Clicking on each heading will take you that section’s medium post.
1. Index
2. Introduction
🖌 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
