Tradle

Tradle is here to answer a question: what does it mean to operate a business on-chain?

Tradle's vision

An emergent global Tradenet, based on bitcoin technology, where trade of the planet's digitized assets is programmed by you, and trade fairness and compliance can be assured with minimal governance.

What Tradenet will do

The Bitcoin effect will go far beyond the restructuring of capital markets. It will change the way we do business, and will give birth to a global Tradenet. Tradenet will use freely exchangeable digital tokens/appcoins to create new business models. Companies will switch to operate on crypto ledger (on-chain) to coordinate activities and establish data sharing with partners, to provide automatic transparency to investors and to better support customers. On-chain operations will simplify value assessment for funding and audit, while decreasing the need for compliance and regulation.

If algorithmic trading on capital markets is any indication, most trade activity will become automated. This will include the trade of physical goods and their digitized representations. It will include and transform existing trade activities like agreements, orders of goods and services, logistics and warehousing, production and quality control, time control and project management, invoices and payments, etc.

As new tools emerge, anyone will be able to program the trade in Tradenet.

Motivation

I have been fascinated with the concept of Tradenet since I first heard it from Cameron Gray in his Bitcoin Magazine article. Cameron defines Tradenet as "quantify anything of value so that it can be traded in a decentralized highly competitive frictionless market". His vision brings to mind traders from Vernor Vinge's Deepness In the Sky, who used open information as a basis for galactic trade. Thus I would define Tradenet as an open-ledger world commerce run on open source, or simply a network of businesses operating on-chain. As commerce becomes a first class citizen on the Internet, it will create stability and livelihood for billions of people engaged in a global trade, not war.

The Internet was born decentralized, but most financially successful sites have grown into monopolies. The dire consequences of this centralization have come into focus with the theft of 100M credit cards from Target in 2013 and became unbearable after we learned of mass surveilance and government hacking into all aspects of our lives. In the bitcoin world, whenever a centralized solution like Mt. Gox emerged on top of a decentralized blockchain, it immediately attracted wrongdoing and regulators. In our current finance system systemic abuse of trust became a norm.

We need a technology that is decentralized and can operate in a fashion which requires no trust in its operators, because if trust is required, it will abused (we must examine blockchain and its new iterations from that point of view, and not trust blindly [that it is 100% trust-less](We must not trust even that (https://medium.com/@lmgoodman/dispelling-some-myths-about-bitcoin-from-a-bitcoin-fan-5b64f3850550)). Blockchain is a technology breakthrough that was born out of 30+ years of research into trust-less and zero knowledge systems. Its open ledger has inspired thousands of bright minds and hundreds of startups to dare to rethink the very structures of our economy and democracy. A new technology stack is forming around the blockchain, with the ability to represent the world with the digitized assets, creating a foundation for global programmable trade. Programmable trade will greatly reduce the amount of delegation of personal powers to intermediaries.

But we have to be careful. As software is eating the world we increasingly begin to trust a new representative, this time the developer. To avoid creating a new subtle layer of trust and retain our personal power, we must be able to program the key aspects of the trade ourselves. We need a way to express complex rules of trade in a simple way.

Backstory

The idea of programmable trade is new, but a more general idea of a programmable Web has been around since at least 1998, when Tim Berners Lee published his book Weaving The Web (see chapter Machines and the Web). We have seen the spikes of excitement around mashable sites, the Facebook platform, and ushered in the age of the APIs at least 5 times over. The achievements of RESTful methodology notwithstanding, the key ingredient of a programmable Web is still eluding us. The greatest concerted push to add this ingredient to the Web was the Semantic Web initiative of Tim Berners Lee at the W3C.

My friends and I were so fascinated with the promise of the Semantic Web that in the early 2000s we left our lucrative corporate jobs and have for over a decade been building systems that operate on a core principle: "Web for humans and machines." In any of the dozens of applications we built, anything the user could view and edit in the application, could be similarly accessed and modified by programs via a single data-centric bi-directional Web API (in fact the UI was built on top of that API). This is in contrast to sites and apps that are built just for humans, with may be a bolt-on, limited, often read-only API, as well as systems that are built just for machines, like EDI and XML exchanges in the past and more recently Web API-based services.

We have built value chain management system where companies coordinated their trading activity across 20+ countries via a decentralized network of corporate Web Databases. This network processed the ordering of millions of tons of products, tracked multi-modal transportation across continents and customs, and organized invoicing and payments, all with a unified trading Web that felt like one site, yet was a network of many. Each participant would login into one of the participating sites and could see everything they needed, yet only related to the business activities in which their company took part.

There was a huge problem. It was really hard to sell this system to businesses, because it required their trust in us, an intermediary that would build and maintain those decentralized Web databases, ensure the quality and especially the security of their sensitive business data. The sales process was slow and exhausting.

At the same time, the results were inspiring. Whenever we managed to acquire the trust of another client, it smoothed out their business processes with partners, eliminated a lot of routine operations and most importantly, improved the relationships between partners in the value chain, as disputes became much more rare. Bitcoin is potentially a game changer for such networked business systems. A trust-less (no trust in an intermediary needed) blockchain allows to build such a trading network on a new foundation.

Wave after wave, technology shifts come and shake the foundation of our existing systems. The companies that venture to do a complete redesign of systems and business models for a new environment take the lead. This is how it was with the shift from the centralized mainframe computing to PCs, and then back to the centralized Web systems, how it was with SaaS, Mobile, etc. etc. We believe with the blockchain we will witness a rewrite of most of the existing business software, software that will not just use the chain to move money, but will intrinsically operate on-chain.

5 laws of Tradenet

1. On-chain operations. A chain can be viewed as a high-level DB transaction log with controlled shared access and custom logic. Decentralized operations, based on a blockchain (or rather sidechains and treechains), will allow businesses to provide third-parties with limited access to their transactions, both internal, like hiring and inventory, and external, like shipments, orders and supplies. It will allow lenders to assess credit scores, investors to do valuations of securities, partners to "operate on the same page." It will afford low-cost compliance, and help brands establish a new rapport with their customers. At this point you may be thinking "no business will do that!", just like many thought "no one would share that!" before Facebook. Relax, we are not talking about opening everything. We're talking about a system with crypto-based privacy controls and anonymity. Think it's a pipe dream? Check out this dreamer doing just that in the medical records space. You can also check out [IBM's IoT on chain project called Adept] (https://gigaom.com/2014/09/09/check-out-ibms-proposal-for-an-internet-of-things-architecture-using-bitcoins-block-chain-tech/) that aims to manage devices' relationships via a blockchain rather than a cloud.

2. Appcoins-based. An entity will be able to offer appcoins as a pre-sale for future use of its products and services. Appcoins is a breakthrough for monetization of open source, finding the best talent to build the product, capturing early adopters (source). It is similar to purchasing tokens for use in laundromats, loading trips on a subway card, or paying for future products at Kickstarter. Appcoins may look like shares of the company, but they can not be, at least not in the US at the moment (fall 2014). In US public solicitation of funds in exchange for securities has been prohibited for 80 years, but this regime is changing. Based on JOBS Act of 2012, SEC has allowed public solicitation if purchases are made by verified accredited investors. CFTC has just followed with a similar rule for [commodities-focused funds] (http://www.reuters.com/article/2014/09/10/us-cftc-funds-advertising-idUSKBN0H51QK20140910). This compliance regime is expected to be further relaxed for small offerings, per JOBS Act of 2012.

3. No appcoin issuance without on-chain operations. This may sound harsh, but the call for transparency is one of the most persistent themes in any recent appcoin project. Running business operations on-chain will ensure automated transparency, essential for investors, and hopefully will provide the basis for satisfying regulators.

• Note that transparency is the main condition of a good Kickstarter campaign.
• Note that publicly traded companies in US are required to satisfy transparency requirements by filing their performance (SEC Forms 10Q, 10K), officers buying/selling company stock (Forms 3,4,5 - so called insider trading), management changes (Form 8K), etc.
• Note that social profiles are now often used to build an online credit score. It is effective as faking a whole network of connections is extremely hard. Assessing an entity's credibility is essential in global trade. On-chain transactions will not only provide an audit trail, but most importantly they will connects Tradenet nodes, building the first social [business] network.

4. Programmable by you. Literacy in reading and writing trading rules is essential for Tradenet to remain trust-less. Like basic literacy, it frees the trader from total dependency on intermediaries, in this case - developers. But will people be able to program? A great web site IFTTT demonstrated that regular people can do it, given the right tools. We call this type of programming micro-scripting, and in our startup we playfully call these trading scripts - tradles.

5. Self-governed. Conflict resolution will be based on programmed trade rules, written and read directly by participants and executed automatically by the system. For conflict resolution these programs will use monetary instruments like escrow, fidelity bonds, insurance, etc., in lieu of legal actions, in the style of lex mercatoria. It is especially important in global trade where legal systems are incompatible, and in the case of developing countries, often underdeveloped and/or corrupt.

Examples of future Tradenet applications

With the advent of bitcoin's decentralized model a new maxim was coined by David Johnston: anything that can be decentralized, will be decentralized. Below are just a few examples of apps that will take advantage of operating on-chain. At Tradle we are building the tools for making and running such apps.

• mutual CRM - record my interactions with companies, like insurance providers, wireless operators, landlords, home repair, etc. Today we call them and they take notes, notes we never see. Notes they may deny they took next time we call. Tell me you were not infuriated by this at least once in your life. This can be expanded to warrantees, repair plans, subscriptions and other committments companies make to us, as well as records of whether they delivered or reneged on those commitments.
• supply chain management, order management, logistics. This field requires multiple partners to be "on the same page," a no go when each has its own internal system.
• personal and business accounting, based on triple entry accounting
• smart contracts: The biggest excitement in the bitcoin world is centered around the notion of programmability of money, with the key concepts being smart contracts and smart properties, initially published by Nick Szabo in 1994. Algorithmic trading is a form of a smart contract that uses outside data, such as market pricing data, economic indicators and millions of other signals to make financial decisions.
• algorithmic trading. In the past decade most capital markets became fully electronic (the new bitcoin markets were born electronic). This opened the doors to an algorithmic trading revolution. Top Wall Street firms trade 100% algorithmically, yet individuals and smaller firms are largely behind. Trading hours are 24/7 in currency and the emerged crypto-currency markets. The amount of assets traded is skyrocketing, with the introduction of hundreds of alt-currencies and emergence of appcoins. Without algorithmic trading, human traders will not be able to compete.
• energy usage and trade based on smart thermostats, solar panels and other renewable sources
• share-a-ride and other resource sharing schemes, especially with dynamic pricing

Future areas:

• securitization of everything, rent out your backyard for farming, your roof for panels, etc.
• discovering e-commerce opportunities - auto-comparative shopping
• e-commerce syndication (after market integration into e-commerce site)
• IoT: automatic auctions between cars and garages, programming doors locks for renting, programming lights to act as a theft deterrent when the host is absent, fridge shelf sensors for tracking and auto-restocking groceries, etc.

Micro-scripting

You-do-your-own-programming is Tradenet's law #4. Our approach is micro-scripting. We hope that drastically simplified scripting will create the same effect as Twitter's micro-blogging - make it ridiculously easy to make and share new stuff. To that extent Tradle provides an app to tap-tap your way into a complete micro-script, a tradle.

Ethereum discussions are centered around the possibilities opening up with the Turing-completeness of their script. We would like to present a different programming model. If you look at Ethereum contracts, or any code for that matter, you will see a lot of scaffolding, with the key decisions, buried somewhere in all the mess. We want those key decisions to be right at the surface. Below are some of the ways we are employing to achieve that:

• variables - an old method used pervasively in declarative systems to avoid writing code. Like in an IFTTT recipe, a tradle's input events become variables. Variables can be used to declaratively fill in properties of a tradle's actions. In algo-trading the action is a trade, and one of its properties is a ticker for the financial product to buy/sell. This ticker symbol can be filled in automatically, for example from an event that catches an anomaly in the specific stock price, or a crypto-currency pair.
• profiles - similar to bluetooth profiles, they allow the creation of a domain-specific context. Profiles will have their own set of technicals, types of rules (e.g. in algo-trading rule a > b will have a extra clause and sustained for 1 day), choices of actions (e.g. in algo-trading it is an order to buy/sell and in a supply chain it could be pay the invoice, etc. Examples of profiles: algo-trading profile (the only one we have at this point), company formation, funding, b2c, b2b, a legal agreement (smart contract), etc.
• models - models are used pervasively in modern apps (MVC). But rarely are models treated as first class citizens. Over the years our team has developed the methodology for making apps simpler by arranging the code around models, and computations around data changes. I think this is what object-oriented programming was meant to be - look at the world, reflect it in your objects and let your users interact directly with them.
• technicals - we borrow this term from algo-trading, where the raw value, like the price of the stock, is processed using some algorithm (e.g. Moving Average), and the result, called a technical, can be used by a rule in lieu of the raw value. Having preprocessed values as inputs, allows a tradle's main logic to remain simple. At the moment we have a built-in set of such functions, but in the future we will provide a plugin mechanism, so that the library of technicals can grow.
• chaining - a tradle firing can serve as an input into another tradle. This helps chunks of logic remain separate and well understood, yet allows to assemble more complex logic from small building blocks.

There is a cop out - you can write your own tradle code (today in Java, tomorrow in JavaScript, Python and other languages). But we consider this coding freedom only as a way of experimenting with the new use cases before they are understood and programmable by non-developers.

Full application stack for Bitcoin 2.0

According to bitcoin core developer Gavin Andersen, off-chain data and computations is the next bitcoin frontier: "all of the really interesting complex contracts I can think of require data from outside the blockchain"

Ethereum captured people's imagination on the potential of extended on-chain computations with a second highest crowdfunding in history - a cool $15M. Ethereum's innovations such as per-contract storage, arbitrary scripts, pay forward computations (gas), etc., allow to implement a whole new class of apps. Yet there is a much larger class of apps that will emerge between the web/cloud and the chain.

In the bitcoin world these apps are traditionally called Oracles. Vitalik in Ethereum and Oracles writes: "The most common case that will appear in reality is the case of external data."

What are the requirements for the new chain-centric application stack? Some of the questions are:

1. Do computations need to be performed by the chain, as in Ethereum or separately from it, with the chain only incorporating a proof of the computation's validity?
2. Does storage need to be provided by the chain, as in Ethereum, or separately from it, as in MaidSafe?
3. How to incorporate external data from Web sites, Web APIs, legacy systems?

Yet reality is not black and white. We believe that Tradenet computations will need to span all these tiers:

1. on chain (whether Ethereum, Mastercoin, etc. or side-chains), providing the basis for complex multi-party arrangments, going beyond the script in currrent Bitcoin's blockchain.
2. on oracles, executing user defined rules. Oracles run on untrusted miners machines (farmers in Maidsafe parlance).
3. on data nodes, for interfacing with existing web sites and legacy systems, for ensuring data security with proofs of existence, proofs of process, and for the dissemination of data/events to oracles. Data nodes work behind the firewalls and can interface with wallets.
4. on mobiles, to construct UI and access device APIs.

We believe that Tradenet storage will also need to be on all of these tiers:

1. on chain, - for proofs of consensus, existence, value, etc., This does not mean Ethereum's storage is not a good idea, it is extremely useful for creating stateful smart contracts without hardcoding contracts into the protocol layer, like Mastercoin, Colored Coins, etc. But Ethereum's storage is not suitable for much larger volumes of application data, which need fast retrieval mechanisms, need to be secured, etc.
2. on oracles, - this storage will be in a form of an encrypted transaction/audit log. Keys will be put into the chain blocks, while values will be stored in an extremely scalable key-value store. Unlike public chain data, this type of data requires security (object level and property level), bandwidth, low latency, significantly large space. Those are the requirements that regular bitcoin mining nodes and Ethereum nodes will likely not meet. MaidSafe's model of grading the capabilities of farmer nodes is more suitable here. Note also that in Ethereum a contract's storage is open and public, which is unsuitable for business data. For example, a logistics provider only needs to see payments pertaining to the cargo it is contracted to handle, and only needs to see parties and locations in those payments, but not the amounts or any other details. For that each object needs to be encrypted with the public keys of users who can access it (object level access), and decryption must render only the subset of properties that this particular user can have access to (property level access). Note that this storage does not necessarily need to reside directly on oracle nodes, which will allow oracles to run on small machines, possibly on android phones.
3. on data nodes, - this storage tier uses a more traditional richer database (whether SQL or NoSQL) that is formed by syncing data from the chain + oracles. This database is suitable for searching, browsing, filtering, etc. to enable business operations, and will need to support massive data archives, suitable for analytics. This storage is also used for syncing with the existing Web sites and legacy systems.
4. on mobiles, to keep a local database for disconnected operations. This db is automatically synced with the chain, oracles and data nodes.

There have been a lot of discussions on oracles in the past couple of years, but only recently several companies released implementations: Ripple's Codius.org, Orisi, RealityKeys, etc. (Note that Codius's whitepaper refers to several more oracles systems). Each implementation focuses on a subset of the functions listed below:

• sandboxing: this technique protects host machines, e.g. a miner, from untrusted and possibly misbehaving contracts. Ripple's new Codius.org uses NaCl - google native client. A Rackspace-sponsored ZeroVM, an offshoot of the NaCl project, could be used instead. Both ZeroVM and NaCl provide a deterministic environment to ensure that identical computations achieve identical results at identical expense. This comes at a price, as some things are intentionally blocked in this environment, like access to the outside world. Another, much more flexible, sandboxing solution Docker has recently become very popular, but it only provides deterministic deployment, not execution. In addition, both NaCl and Docker sandboxes can run inside a full Virtual Machine, like VirtualBox to fully isolate the host machine from possibly misbehaving smart contracts.

• proof of untampered execution: Sandboxing protects the host, but the opposite is needed too. In a decentralized environment, hosting of apps is done by untrusted parties. This is in contrast to current cloud settings, where we implicitly trust Amazon, Google, Microsoft, etc. In the post-Snowden era we know that this trust was misplaced. So, in building a new distributed cloud, especially one executing financial transactions, we must trust no one and rely on cryptographic proofs of data immutability, code immutability, and computation verifiability, by applying zero knowledge systems pervasively. A recently invented technique called zk-SNARKS allows something that is hard to imagine: verification of computations without repeating them.

• securing external data: Trusty URIs (hash-URIs), Notary Chains, proofofexistence.com and Reality Keys tackle the question of whether we can trust a website's data. Hash-URIs of all the data inputs (including hash-URIs of all dependencies) combined with the hash-URI of the code, can provide verifiability of public computations. Any other network node may do the audit, by performing the same computations and verifying the resulting hash-URI. Great for open source code and fully open data. If some private inputs like secret keys, must be included, then zk-SNARKS technique must be used.

• communicating decisions to the chain: Today there are a multitude of solutions based on multisig, split secret, etc. The most promising is Adam Back & Austin Hill's new sidechains startup called Blockstream which will allow oracles to run as nodes in a sidechain, with direct integration into the bitcoin mainchain.

• consensus between oracles: Orisi uses M of N multi-sig to work around possibly compromised or unavailable oracles. This replaces the "everyone agrees" notion of the blockchain with the "some agree". May be with Adam Back's sidechains this compromise can be avoided.

• user choosing oracle nodes: this is Codius's approach to securing computations by relying on each node's reputation.

• rendezvous and communication. Oracles need to discover each other, users need to be able to discover oracles. A mix of techniques used by bitcoin nodes, like DNS seeds, broadcasting known nodes, etc., can be employed.

Tradle will use the mechinisms above and add two innovations to make smart contracts simple:

• a) non-developer (DIY) contracts. A simple rule based UI designed to be used on mobiles, so that no developer is needed as an intermediary to make and read contracts. The complexity of programming is moved to data and a growing number of functions defined on data.
• b) data unification. We use a visual data modeling framework and a data mapping engine, developed over the last decade, to make web data accessible to smart contracts.

Tradenet: oracles and data nodes

The Tradle app compiles a tradle into Java code, which is executed by oracles. Oracles subscribe to events from Data nodes and pass them to tradle code. This way tradle code can be simple and verifiable.

Oracles engage in bi-directional communications with data nodes. One flow we already described in the mobile apps architecture section, where the user is the source of new transactions. The flow in the opposite direction originates in the external world as changes in external Web sites, such as government open data, exchanges, and apps that generate events via their Web APIs. Data nodes use the data modeling framework to make sense of incoming data and special adapters to read data from all those disparate sources. Data nodes then present data to oracles in a unified way.

Oracles perform the following functions:

• Subscription. Specifically, oracles send tradle URIs as subscription requests to Data nodes, and wait for events on WebSockets. A tradle may have several input indicators, so oracles will get subscribed to several event types. To compensate for reboots and re-connections, in a subscription request oracles say: give me new 'if-modified-since' for each tradle indicator.

• Verification. A data node publishes every event with its hash-URI and sends it to Notary Chains. Oracles verify each event's hash-URI with Notary Chains.

• Synchronization. Each data node may provide different indicators. Indicator URIs reflect the nodes they are coming from, e.g. http://server1.tradle.io. Thus oracles may send subscriptions to several Data nodes (if all indicators are on the same server, it sends one request with 3 indicators in it). Events in each indicator come at different times. Oracles save retrieved indicators into their local databases. This way when any event arrives, oracles can call tradle code with all the values of other indicators it saved before.

Tradenet: oracles and the blockchain

Each tradle has actions. In the case of algo-trading, actions define what assets to trade, in what quantities and at what prices. A tradle's code does not have access to this information. Neither do oracles. In order to execute actions, oracles send transactions to data nodes, which have access to wallets and actions.

This scheme is not perfect. There might exist a crypto scheme which does not require two steps and will allow oracles to initiate actions, without knowing what those actions are. Please let us know what crypto scheme we should use.

Another problem is that to communicate with the wallets, oracles will need wallets' API keys, and it would be totally insecure to give oracles those keys. May be an approach could look something like this: an oracle hashes a tradle's decision (combined with the hashes of inputs, a hash of the oracle's code, and a hash of the tradle's code) and puts it into a crypto box. Wallet picks final hash from this box and proceeds to execute trades on a tradle. Standard wallets do not have this capability, so we will need to look to at wallets that allow custom plugins, like Omniwallet.

New application stack from mobile point of view

Modern mobile apps use a device's local database as their primary database (this is also true of Web apps that use IndexedDB or WebSQL, see for example our own Urbini. Such apps paint the screen from the local db and they record user input by creating transactions in the local db. Synchronization of data with the cloud db happens in the background. This flow has evolved from the "always connected" flow of Web apps due to the necessity of supporting offline/disconnected operations. Turns out this flow is a great enabler for on-chain apps, as transaction coordination via the chain is slow, yet having a local db on a mobile device compensates for that. For simplicity in this chapter we will assume that the chain is a smart chain = oracle + blockchain, and the cloud db is the same as the data node.

1. Chain becomes a master db. In this setup cloud db becomes a slave db to the chain. Although the chain is a 'master of record', it is not a database which can be used by apps. It is similar to how blockchain explorers, like blockchain.info, work today - they monitor transactions on blockchain and create a browsable, searchable database. There is even a startup, Chain, that offers such services. But for the chain to perform the function of the master db for any kind of business transactions, it needs to be enhanced, fronted by the oracles. Oracles will make decisions, enrich transactions, perhaps generate sub-transactions and send them to the underlying blockchain. The underlying blockchain could be Ethereum, Mastercoin + MaidSafe, Notary Chains, etc. with richer semantics and storage capabilities.

2. Apps bootstrap from the chain. An app's local db becomes a slave to a chain instead of a slave to a cloud db. As an optimization, apps could bootstrap from a cloud db, but verify all the data and app assets with the chain. New transactions are sent directly to the chain, that is when a user fills out some form, buys something, or makes some other choice by tapping the screen, the app will create a transaction and send it to the chain.

App bootstrapping:

App <-- cloud database <-- chain

or

App <-- chain

New transactions:

App --> chain

(TBD: a good diagram)

The above describes the flow when transactions are generated by the user. In other cases transactions are initiated based on events in the real world, as interfaced by the data nodes. In this case a data node sends transactions to the chain, and itself keeps an archive of originating events. In the future a more complex archival technique will need to be developed, so that the chain does not grow out of hand. Perhaps a sidechain will emerge that will have slow access, yet vast storage capabilities.

Runtime

Tradle provides simple UI tools for anyone to be able to program trade. Each user program is called a tradle (at this point we provide a tool to create tradles for algorithmic trading). When a user publishes a tradle, our tool generates tradle code for execution. Oracles execute a tradle when they receive an event the tradle is configured for from the data node. Oracles will not be HTTP servers (will not accept REST requests), so they can run in any environment, even behind the firewalls, like other p2p programs. That said we are working on a simple protocol to facilitate communication with oracles. At this point it will be a form of push messaging.

The first oracle implementation will be in Java, open sourced in this github repo. It will be designed to run on Android or Oracle Java, so potentially it can run on any OS and even on Android smartphones. Developers will also be able to write tradles manually, necessary for prototyping and experimentation in new business domains, yet to be eventually replaced by tradles created by users.

Miners will only need to download and install the container process. Oracles will be automatically deployed into those containers with the use of Docker, running in a CoreOS inside a VirtualBox. CoreOS is a stripped down Linux OS that runs every app in a separate docker container and allows to automate docker deployments across a cluster of CoreOS instances. Together with the Java virtual machine this should provide a high level of sandboxing to protect host machines from potentially malfunctioning or even malicious tradle code. Alternatively Maidsafe's orchestration capabilities could be used for deploying and migrating oracles between farmer nodes.

At this point tradles will receive events as input parameters and return true or false, which will initiate actions specified by the user on the tradle. Tradle code will not have access to the action, and will not know what is at stake. Our goal is to make the oracle implementation extremely small so that its security can be easily verified.

Conclusion

Tradle is developing a protocol for running business operations on a distributed cloud powered by the blockchain. As transactions include multiple business participants, these relationships will begin to form a Tradenet of connected businesses. So possibly another definition of a Tradenet is a decentralized social [business] network.

Who is Tradle

Tradle is a self-funded US company, registered in May 2014 in Delaware, and operating in New Jersey, close to New York City. Tradle brings to the table its team's prior intelectual capital in the form of a distributed Web Database used to build dozens of Web apps based on model-first technology. This Web Database was born out of Semantic Web ideals, and evolved to shed many of its shackles. It is written in Java, not yet open sourced, but all sources are in GIT and have only open source dependencies. It is the closest to what we called data nodes in this paper. We also bring an open source offline-first mobile web client, which can be used as a core for emerging on-chain mobile apps. We used this client and the Web Database backend to create an algo-trading marketplace Tradle.io.

Tradle is currently centralized, but we are redesigning it for the decentralized operations based on the ideas introduced in this paper. We have started the development of oracles, the third architectural tier described in this paper, and are evaluating the crypto mechanisms that oracles and the rest of the stack will require (several of them we mentioned in this paper). We need much help in building this stack, and hope this paper will serve as a call to join forces with us, technologically, financially or in any way you can. We believe in the grand future of bitcoin, the future we described in this paper as Tradenet, yet above all, we would like to figure out how to use this once-in-a-lifetime opportunity towards enlightened goals.