First, We should note that there is no such thing as “real” world data, as there’s no objective view of reality.
Instead we can quickly survey how data flows from the physical world into smart contracts, and to the 2key smart contracts in particular, and how the various data sources are interplayed in the contracts to serve the contract peers.
On-chain data IS off-chain data, all data sources are centralised, and how to reach subjective consensus
There are a few common misconceptions that we should clarify, in order to enable fruitful communication on the subject.
(1) **First**, we should note that mostly all “on-chain” data originates from off the chain. That is, the participating peers on the distributed ledger all move data from off the chain on to the chain by digitally signing on it in a cryptographically verifiable manner. So all on-chain data, is, in fact, off-chain data, that was signed onto the chain by some peer on the distributed ledger/network.
(2) **Second**, data is subjective by nature, and fluctuates on viewpoints, space, time, measurement device etc.. There is no objective view of reality, meaning there is no objective view of the temperature in Tel-Aviv right now.
In most cases, for carrying out a contractual agreement between peers, all is required however, is that the stakeholders / interest parties in a specific contract’s context agree to some value, regardless of the question whether this value is real/true.
(3) **Third**, we must realise that all data sources are centralised by nature. Data always originates from some source, a device, instrument or human. So data sources are inherently centralised. The sciences of probability, AI, statistics etc.. have developed methodologies to aggregate centralised sources of data in order to ascertain probable values of various variables, always up to some certainty criteria, that is, we can always strive to no better than a common subjective agreement within some context of observers/stakeholders. There is no point in chasing absolute truth as everything we see, witness and measure is subjective.
So ALL data sources are “vulnerable”, in the sense that they will always attest to little more than their own subjective experience/measurement, which may contradict those of other parties of interest in the context of a contractual agreement.
The point in developing DLTs (Distributed Ledger Technologies) is mainly to specify apriori rules of engagement under which a consensus is reached.
(4) **Fourth**, smart contracts in evolved ledgers are Turing Complete, which means they can be programmed to do *almost* anything, albeit some current infrastructure limitations which causes their development (currently) to be specifically challenging, especially in truly decentralised ledgers like Ethereum.
(5) **Fifth**, the usual discussion of on-chain vs off-chain data is missguided in a sense, as it would be better explained as a dichotomy on the ownership of the data. When a peer on a ledger signs some data and sends it on-chain, the question to be analyzed is primarily that of ownership. If this data signifies the user’s vote, opinion, movement of own funds etc, this is still a centralised data source sending data on chain, but in this case it’s data which requests state changes following self-attestations or mutations on data currently “owned” by the user — e.g. his own mind, his own funds, etc..
When a peer on a ledger signs some data and sends it on-chain, but the data is not *recognized* by the other peers in the contractual context as owned by this user, in this case, we call this a “trusted” data provider. In such cases however, multiple methodologies can be put in place in order to make sure that the other peers in the contractual context agree to the value of the data as input by the “trusted” source.
For example, if a contract needs to know the exchange rate between ETH and USD, in order for any consensus to be reached, there must be pre-specified in the contract exactly what the source of the data should be. Like any other non-personally owned data, there is no objective view of what the exchange rate exactly is at any point in time, because clocks differ, exchanges differ, aggregation rules differ etc.. This is why the way to enable contracts to utilise data such as this in a fruitful manner (i.e. which serves the contract peers and gains their approval), is to pre-specify the source, so for example, the contract could specify that the source must by CMC, and the timestamp of measurements as appears on CMC site. In such case, if the signer of the data inserted on-chain is a formal CMC address, no further reconciliation is required, as the subject is again the natural owner of the data and no further attestation/signature is required in order to reach consensus.
However, if it’s some other address inserting this data and signing it on to the chain, their signature binds them to their own report, and so they may be subject to reputation-based rewards/punishments incentivising truth-telling. Moreover, since the source has already been specified exactly in the contract, it’s easy for other parties in the contract to verify the truthfulness of the data before engaging/interacting with the contract. So in such way consensus is evolutionary, in a sense that only those parties agreeing to the validity of the data will interact with the contract in ways which rely on this data’s value, so that any peer participating in the contract is validating the trusted data source by their re-action.
To summarise, all data sources are inherently centralised and subjective, and DLTs and smart contracts can help set the rules for allowing counter-interest parties/peers to interplay in contractual contexts while ensuring all sides that the contract rules will be upheld. That isn’t to say that smart contracts will always guarantee agreement as to the data being input by the parties, but it does mean that the rules of engagement keeping all sides’ interests, at least in good contracts, will be kept, as can be verifiable by each party before entering the contract, and including methodologies allowing contract parties to communicate and resolve disputes when dealing with data which isn’t self-owned by one of the contract peers but is still required for the contract to function.
As evident from above, when all parties of interest in the contract are partaking in a contract, and when all data required for the contract to function is owned by the peers (i.e. no externally-owned peer/data is required for the contract to run its course) — in such cases it’s much easier to pre-ensure zero risk and a pure 1 sum game for all parties. The latter are the types of contracts we strive for as much as we can in the 2key network.
Remind me what 2key network does?
The main objective of the 2key network is to facilitate **Social Sourcing** — The incentivised activation of result-driven online virality.
We’re primarily centered around Social Contracts — i.e. contracts in which humans interact with humans. This means that each 2key campaign is a Social Contract, in which some Contractor wishes to bring about some business result — which requires humans to do some action — e.g. provide information, consume content, answer questions, share personal info, agree to be addressed by the contractor for sales purposes (i.e. become a lead), purchase digital or physical assets, buy tickets, donate for a cause, become a patreon, crowdfund a project, sign-up for an app or service, install an app etc..
Remind me how 2key smart contracts run?
First a quick primer: Contracts on the 2key network are run on the 2key Protocol, which is a multi-party-state-network solution enabling to create dynamic ad-hoc blockchain shards per contract, whereby pressing a 2key link, users’ browsers are transformed into a distributed node in the off-chain distributed shard running the specific contract.
This is to say, the smart contracts in the 2key network run mostly on the 2key off-chain MPSNs, touching the public main-chain usually at contract initialisation and convergence.
Data Flow in 2key network
Having cleared this, data flow in 2key network occurs in just one main methodology:
Data is always cryptographically signed by contract parties, and verified either by
(1) consensus of other contract parties, and/or
(2) cryptogrpahically verified by the contract itself, and/or
(3) statistically/algorithmically validated by the contract itself, and/or
(4) ascertained as true if signed by a trusted party (we call those Integrators), depending on withstanding reputation of the Integrator and incentivised towards accuracy subject to reputation/results driven rewards/punishments.
All user generated signed data flows from the users (in the “real” world) into the 2key contracts, stimulating state changes in both the off-chain and on-chain contracts’ representations, depending on context.
Most user types on the network (Contractors, Referrers, Converters) simply sign on their own data, which means the data can be validated by either
(1) The users’ self-attestation (e.g. opinions, votes etc..) and/or
(2) By mutual agreements/signatures between contract peers (e.g. in Information discovery contracts, e.g. missing person search, the statistics of externally encrypted (hidden) responses may be decrypted and tallied by the contract itself, and validated upon statistical certainty criteria) and/or
(3) By approval from context-permissioned peers within the contract (e.g. in a Lead generation contract, the contractor may publish the contract with self-signed-permissions for qualifying the leads (i.e. conversion validation)).
Integrators are the 4th type of user, they are a special type since they by definition act as trusted service providers in the contract, elected by the Contractor to deliver specific trusted functions in their campaign, such as identity verification, or off-chain conversion validation (e.g. app installs).
These integrators are “trusted” since their services usually entail signing on data which is centrally controlled off-chain, and which cannot currently be validated trustlessly on the ledger, but which can at times be validated or disproved by contract peers’ consensus or lack thereof.
Integrators are heavily exposed to reputation based incentives/fines and are heavily incentivised to faithfully serve the contract parties.
Drill me down to transactions and give me examples
So to better understand 2key contracts you need to drill down into the main transactions taking place. The Contractor initiates and publishes the contract, then seeds it in a sourcing seed — a group of existing peers associated with the contractor in the context of the contract. For example, some SMB looking for new customers can source the campaign link by sending it to their existing customer base via whatsapp/fb/newsletter etc…
Then these sourcing seeds may choose to become referrers, and they may join the contract, pay it forward by forwarding 2key links, and so on in various referral chains until Converters are discovered — humans that are willing and able to convert — i.e. to produce the desired result of the contract. Up till now all transactions have been strictly peers in the contract acting on their own behalf, publishing or relaying the contract, so this is real world data coming in, but its human originated, and signed by the subject-matter humans themselves.
As for Converters, their **actual conversion action** may either happen directly on-chain, or off-chain, depending on the type of conversion. When the conversion happens on-chain (e.g. like buying any asset that has been tokenized on chain) — the conversion validation is self-verified by the contract.
In other cases where conversions happen off-chain (e.g. installing an app, signing up for a web2.0 service/site), there sometimes requires to be an Integrator involved, which acts as a trusted service provider in the contract. In any such case, since all involved parties are stakeholders in the contract, and are subject to reputation-based incentives, there are game-theoretic methodologies that may be employed to make sure that truth-telling is heavily incentivised, while false data can be quickly flagged by opposing parties, and financial losses cut or avoided, while projecting base (network-level) reputation modifications which will weed out bad actors from playing part in future contracts.
The whitepaper (linked from https://2key.network) explains more in depth which types of trusted service providers (Integrators) may serve in the network. For now, as I outlined before, the main functions that require Integrators are (1) converter validation — i.e. identity validation (kyc) where identity is generated by a central government , (2) conversion validation, where conversion happens off-chain.
As we designed the network, the types of data handled by 2key contracts are easily triangulated by the contract peers, so that combined with feedback mechanisms, peer consensus/votes and reputation based incentives, the network drives peers to accumulate positive results and feedback.
Temperature in Tel-Aviv, as other physical variables, are very luckily out of the scope of our contracts, otherwise we’d have a rough time, since probably no 2 people/devices will agree on what the real value of these variables is at any given time. As explained above, there is no objective view of reality, so trying to find contractual agreement based on physical, non-human-specific data which is subjective to space, time, point of view, measurement etc.. is bound to fail, unless resorting to an agreeable subjective value for the data, which is OK for the specific peers in the contract to accept.
In any case, in 2key network we aim to only handle contracts where humans interact with humans in order to find humans that are willing and able to produce desired results. When these results do not happen directly on the ledger, sometimes it’s required for additional moderators/integrators to take a trusted/faithful part in the contract, which they earn a fee for as long as they do so without incurring bad reputation, while staking funds which they may lose if they do acquire bad rep.
Off-chain conversions in general may be declared by the Contractor, or a Converter, or an Integrator, and usually require to be verified by other parties for funds to flow.
In such cases, these data inputs as to whether conversions declared have actually happened or not, are manageable in terms of liability and trust by requiring multi-sigs of various counter-interest stakeholders in the contract. Only by humans agreeing on events can funds flow, so all parties are usually in a 1 sum game, where it pays off for everyone to be truthful, and pays little to nothing, and often costs heavily, for anyone to lie.
The contract can act as a trustee until sufficient handshakes are aggregated to warrant state changes in the contract following off-chain events. Some integrators may also act as insurance providers or dispute resolvers, to enable contracts with zero risks for converters and/or contractors even in these more complex off-chain conversion contexts, but these are the most sophisticated types of contracts and require quite a lot of algorithmic game-theory behind them. For most of the campaign types in our immediate future, these will not be required.
Contract roadmap for 2key Network
Practically, we’re starting with pure on-chain conversions, and are going live with digital asset sale campaigns, where the assets are tokenised on-chain. Following, we’ll cover donations, patrons, crowdfunding by the end of this quarter hopefully — these too are basically tokenised conversions, but with some inherent risk for converters in terms of receiving the purchased asset, which is integral to the contract, but which is also mitigated by the contractor’s will to keep a high reputation to ensure continuation of funds.
When we start handling off-chain conversions, these will initially be cases where the contractor acts as the conversion validator, and where the converters are also basically being paid by the contractor, as well as becoming interest parties in the contractor, so that’s it’s in the contractor’s interest to see these conversions through.
For example, an exchange running a multi-step referral campaign using 2key, can integrate the 2key-protocol into their app or website, and thus the exchange becomes both a contractor and an integrator in their campaign for getting more users to onboard their service. Whenever a user joins the exchange, the exchange app/site will be required to send a signed piece of data which signifies that the conversion took place.
In such case, the contractor has full interest to keep the contract, as these conversions have multiple stakeholders in the form of existing and new users of the contractor’s own domain, and playing the one possible malicious act of not reporting a conversion, will quickly have negative effect on the contractor from multiple sources, in the form of bad reputation, converters which can attest to having converted, and having other peers on the contract attest to it, and thus having a reputation standoff between the contractor’s words and the converters, in such case where converters attest to some conversion that happened but wasn’t reported. Additionally, these converters who the contractor tried to cheat are actually users the contractor wants to onboard, so there’s absolute negative value for the contractor to try and cheat them out of their signup reward..
Again, as in these cases the contractor is validating conversions of his own app’s users, it makes little sense to offer them something, and then try to avoid, especially since there’s a smart contract and an underlying reputation network in the background handling interest of all sides. Even in today’s purely trusted one step referral programs like we see in many web2.0 sites and apps, there is hardly a case where the app owners try to “not declare” a conversion, it’s simply not in their interest.
Same goes for content distribution, where publishers will be able to integrate a 2key protocol “share widget” and activate campaigns incentivising their readers to bring more readers. Having all parties of interest in a 1 sum game is usually the 90% of the way to ensuring good contract outcomes. As said, the contractor also stakes funds in the contract when publishing it to make sure the converters are guarded against a one-sided default by the contractor.
One of the great aspects of the 2key network — is that an ad-hoc “blockchain shard” is created per contract, in such a way that on any atomic issue, consensus needs be reached only by the specific and direct stakeholders relevant to the issue. This greatly enhances scalability, as it allows to converge sophisticated consensus mechanisms, both statistically “hard” approaches, and more “fuzzy/subjective” game-theoretic approaches, making sure participants in 2key network can “trustlessly trust” their interests will be kept.
Thanks for reading!
