Skip to content

Home

Jump to bottom Edit New page
Link Swanson edited this page Aug 3, 2015 · 46 revisions

Tradle is a blockchain startup dedicated to creating a trust layer for the Internet.

Site: tradle.io
App: Trust in Motion (TiM), the preview and the screenshots
Devs: TiM source

Please note the sidebar with other articles.

Community

Tradle is a community that shares a belief that freedom and commerce are necessary ingredients for happiness and that the blockchain gave us a way to trade fairly and directly reducing any forms of governance to a minimum. As Lawrence Lessig famously said Code is law, and the blockchain embodies this principle like no other software before it.

Vision

We are building a decentralized commerce network, which we call Tradenet (hence a playful name Tradle), and for that we need some basic building blocks. First step is to enable the blockchain to provide consensus for any database transactions. A dominant centralized SaaS model, e.g Google Docs, Salesforce, provides a lot of benefits for collaboration by sharing data and business processes. But as we learned in the last couple years, the SaaS model is flawed as all the data are up for grabs by the cyberattackers and the governments. Unfortunately as a society we spend years discussing and legislating 'do not track' cookies policies by companies, but tolerate total surveillance of all our communications.

The government overreach will cost cloud and SaaS providers $180B in the next five years, according to the Forrester Research. The backlash in Europe and Asia against US software companies has begun and there is but one solution in sight to this problem.

It is time to create an architecture that does not lend itself to so much concentration of data in one set of hands. Our dream is for this architecture not only to restore our constitutional rights, but to empower allow individuals and small teams to outperform large corporations. We believe that the emerging un-marketplace will allow coordinating activities of many entities and properly reacting to market changes.

Blockchain - new type of data structure

  1. Bitcoin's blockchain is the first ever organizationally decentralized and logically centralized transaction log.
  2. It is a log, not a database, yet it can be used as a master in a master-slave design pattern, where the slave is a normal SQL or NoSQL database.
  3. It is the first log that is highly tamper resistant. Never before we had security as such a dominant design goal. In this age of hackers and government indiscretion the blockchain can be used as a foundation of a new software stack.

To explain the above statements:

  • In the past the organizational centralization was required and with it an absolute trust that the transactions will be preserved unchanged, and will be properly sequenced and timestamped. We trust banks, government agencies and e-commerce sites among many others to provide such guarantees. Blockchain's organizational decentralization greatly reduces the trust needed and achieves these guarantees on a global scale.

  • In the past decentralized systems were hard to make compatible. But blockchain is logically centralized, which makes it a great way to achieve sharing and compatibility between applications.

  • It is much less than a database, as it does not allow efficient searching and filtering. It also does not allow data to be modified. Yet we can import transactions from the chain into a normal database. A blockchain explorer, like blockchain.info and a commercial API, like chain.com is in fact a slave database to the blockchain.

Big problem - scalability

Although the blockchain can be used today for storing database transactions, it does not scale well. A normal bitcoin transaction has several inputs from which the bitcoins are transferred and several outputs. It does not have space for any other data, a normal db transaction would need. So the approach used today, called meta-protocols (e.g. Mastercoin/Omni, Counterparty), encodes extra data into a bitcoin transaction in different hacky ways. One of the most popular hacks is to create 1 of N multisig transaction and encode data in the N-1 outputs. Every blockchain node keeps the replica of all past transactions and the size only continues to grow. The problem of scalability is perceived to become so severe that some pools started to censor meta-protocols although the are not yet so popular to have added considerable bulk to the blockchain.

We are designing a metaprotocol on top of bitcoin's blockchain that allows transaction to carry additional data outside of a blockchain, yet preserves the same consensus guarantees and provides even stronger guarantees for data privacy than existing metaprotocols.

This new protocol stores data on another p2p network with high reliability. We came up with several designs (and so far prototyped one of them). For the underlying DHT and files we used TomP2P, explored OpenKad and have now rewritten with bittorrent-dht which is battle-tested as part of the Popcorn Time app, used by millions of users.

We do not want to turn the blockchain into a full blown database, but rather we want it to serve as a global transaction log, with which we will synchronize our databases. We are aware of different decentralized storage mechanisms, like Permacoin, Filecoin, Maidsafe, Tahoe-LAFS - good ideas there - but none of them quite fits the bill, as first 2 have their own blockchains, Maidsafe does not use the blockchain and Tahoe is not fully decentralized (open a github issue if you disagree). We want a design that is specific to storing transactions, not large media files, one that derives its security properties from the blockchain, does not introduce a new blockchain and has high encryption guarantees - not only the transaction body is encrypted, but also its location in p2p network. We also want to provide dynamic access rights allocation, so if I sent you an order, you could later share it with your accountant.

We discussed the subject of "blockchain + DHT" with the bitcoin core devs Matt, Jorge, Pieter and Mike. They all agree that this is not a simple goal to achieve and they expressed a concern do not bring DHT security problems into the blockchain, and "do not bloat the blockchain".

Our goal is to have the bitcoin blockchain secure the DHT, without any adverse effects on the blockchain. In return we will allow people to use the blockchain for very complex transactions with the minimum and politically correct bloat (using 40 bytes in OP_RETURN. This is not a completely new idea, as far as we know Mike Hearn was first to publish an idea of extending the bitcoin with the DHT for the purpose of allowing more complex transactions needed for bond trading on blockchain. Another example is twister. What is new with Tradle, is an attempt to create a generic mechanism to extend the bitcoin for any transactions. Another new thing that Tradle offers is a full software stack to create blockchain-based Enterprise infrastructure and blockchain based apps.

Example

Let's take an example decentralized app (dapp), say a clone of Airbnb, and discuss its scalability and security (they are intertwined). This dapp will have 2 main transactions: listings and negotiations messages. Listings are public, but messages are not. To make the messages private we could include only a hash of a message on a transaction, while putting an encrypted message body elsewhere outside of the blockchain, say using some DHT for locating and DFS like bittorrent for storing.

This addresses security and helps with the scaling.

  • Security: the message will be readable by both the sender and receiver, but no one else.
  • Scaling: the bulk of message storage will be outside of blockchain nodes and the level of replications could be fine tuned, to say 100x, not all of the blockchain nodes, which could be in the thousands.

Transaction Validation off-chain

In the example the contract code can not now read the [encrypted] booking message, thus it can not validate it, e.g. check the booking dates against the listing's schedule, check if tenant is approved by the host, check that the price is matching the listing / special offers, etc., etc.

So the contract (and any of it's validation rules) can now only be executed on the edge nodes, nodes that have access to the wallet which has keys to decrypt the transaction's data. This dapp requires new contract execution infrastructure. If you do validation on the edge, you need to solve hard problems:

  • validation consensus problem. Each edge node may have a different version of a contract engine or may be even an implementation in a different language. Consensus may not be reached and network will split.
  • problem of creating an SPV client. If blockchain contains tx that is not valid from the point of view of the edge node, then SPV is not possible.
  • Luckily, not all validation rules need the whole network to agree. If I am sending you an order and your validation rules do not pass, your node can mark this order as invalid by creating a new version of the object on the blockchain. If this 'invalid' flag is one for all types of transactions, then reaching consensus and the SPV become possible again.

Choices of embedding mechanisms

Bitcoin was not designed to carry other transactions but moving one type of value, the bitcoins. So, to extend it to move other assets and to move any kind of DB transactions we need a bit of trickery.

  • The kosher way. As of version 0.9 Bitcoin offers a method to carry 40 bytes of metadata. It is referred to as OP_RETURN. OP_RETURN adds very little bloat to the blockchain and makes such bitcoin transaction outputs provably spent, so it does not bloat the most precious blockchain resource, called the UTXO (unspent transaction outputs). But is has a disadvantage of being highly censorable.

  • A more controversial, 1 of N multisig, used by Mastercoin and Counterparty, is also prunable, if at some point this 1 of N payment is spent (Mastercoin supposedly provides a sweeper utility for that, not sure about Counterparty though).

  • Another method, P2SH with 1 of N multisig is considered even less resource intensive for the bitcoin blockchain as P2SH outputs are not included in the UTXO. This method requires a redeeming script to be stored off-chain, possibly in the DHT. This method is new and requires more research.

Future

This is all good news for those of us who believe that we are entering a new Internet era, as important as when the Web was born.

Add a custom footer

Design

###Software

###Front end

Clone this wiki locally