Howdy from Eris Industries

Development 3rd Party
1

Howdy Counterparty folks - Preston Byrne from Eris Industries here.

The reason I’m here is because we’ve been chatting back and forth with Counterparty bods over the last couple of weeks about our platform and XCP, and wanted to engage a little more formally.

By way of introduction, Eris is a distributed application platform with smart contract capability - not a cryptocurrency. Accordingly, our project isn’t designed to be a standalone blockchain, but something which allows various distributed protocols to talk to each other in a single application (“silo-busting,” if you will). And they’ll do so through a normal web browser at localhost.

We’d love to have a conversation about how we can help XCP increase its reach by supporting interoperability between your protocol and other protocols, including Thelonious-based DApps (Thelonious is our open-source blockchain protocol design). To encourage people to get on board we’ve created the #MarmotAward, the highest honour our company can bestow in peacetime, which will be awarded to the first person who writes a module for Eris which will allow Eris DApps to talk to the Counterparty protocol. See: https://blog.erisindustries.com/products/2014/12/19/marmotprize/

I’ll spare the details as to how it works here on the forum (if you’re interested we have a very full exposition of how it works here - https://blog.erisindustries.com/products/2014/12/27/step-by-step-eris/ - and elsewhere on our website but long story short, it has two main components:

A) a blockchain back-end we call Thelonious which holds the application logic for a given application. Thelonious is designed to be secured without mining; like its uncle Ethereum, it is smart contract enabled, but it is also smart contract controlled - meaning it can do some interesting things like

-secure itself without mining,
-amend its parameters over time without a hard-fork and
-control which users have write permissions on the blockchain.

It’s not a single blockchain administered by EI, but a blockchain design which is designed to spawn many millions of blockchains of its class, each of which is controlled entirely by the developer deploying it. It is designed to hold application logic (arbitrary data), not tradable units of value - although as the design is open-ended devs can frankly build what they like on it.

Accordingly, we aren’t selling any tokens - Thelonious is using a blockchain as a pure open-source database technology, so devs will own and run and be in control of every aspect of their applications, not us.

B) The distributed application server, or Decerver (see: https://decerver.io/tutorials ), which is designed to allow these applications to plug into other distributed protocols such as Bitcoin (QT and BTCD), Ethereum, and IPFS. BitTorrent support is in the pipe and any other protocol (including XCP, per the bounty) can be supported by simply writing a module wrapper.

We’ve currently got a Hello World DApp and will be releasing something a little more advanced (distributed YouTube) in about two weeks.

Between now and then, though, we thought it’d be good to pop over and get the conversation started! Looking forward to continuing the conversation in 2015.

2

Preston, Where can I find a simple outline of how Thelonious secures itself without mining? Is it not using a consensus mechanism? This is all I found: 

To ensure that other entities are not able to participate in the chain, the blockchain designers may parameterize the Thelonious blockchain such that only three private keys from each of the twelve entities may send transactions, create smart contracts, or commit (Thelonious’ equivalent of “mining” in other blockchains) blocks.
That would suggest that you’re using a voting mechanism, without coins being awarded in any way. This sounds like an quorum-based eventual(maybe?) consistency mechanism, not a blockchain. 

If so, that means it’s secure because (Pick a few):  there’s no counterparty risk, Nothing is as stake, it’s not a blockchain, there’s nothing in escrow, there’s nothing to take, (probably more). These systems have been around forever (here’s a paper from the 80’s) The reason they’ve not taken off is because no-one has this problem.

3

Here you go Preston, show this to your dev team: https://www.quora.com/Database-Replication/What-is-Quorum-Consensus-algorithm 


They have not built a consensus mechanism, or a Blockchain. You should remove both those words from your literature if you’re interested not getting ripped to shreds by an accomplished and competent computer scientist. 

There are some things you’re doing with your project that I’m very appreciative of. But it is in no way decentralized, or secure, by Bitcoin standards.
4

Howdy Chris.


We aren’t designing a cryptocurrency. We’re designing a distributed application stack that uses a blockchain to hold the logic of an interactive application like Facebook, Twitter, or even this forum. 

Because we’re looking at arbitrary application data (e.g. magnet links to cat pictures or a pointer to an encrypted file on BitTorrent), we are focusing on the fault-tolerant aspects of blockchains, not the “decentralised consensus” aspect known to most users of Bitcoin. Consensus/unanimity is important to ensure the database is consistent. It is not, however, required (in this context) to protect representations of value - as the data in itself is valueless (and only acquires value in a real-world context). 

This should be distinguished from something like Bitcoin or Counterparty where the data in itself is the asset. With Thelonious, value can be transmitted but the character of any data which is valuable is determined by the facts and circumstances surrounding its transmission, much in the same way a regular database works today with, for example, a clearing system. 

For this reason, Thelonious is not one chain. It is a template for developers to build their own. For interactive applications (social networks, communications, DRM), it is entirely appropriate to explore alternative consensus measures - users lack the technical sophistication to participate in the management of their data on, e.g., Facebook, and this is no different. We don’t want to be involved every time Facebook updates a widget or how a “like” button works; we simply want to use the application and for it to work. Accordingly we give developers the power and the responsibility to manage applications run on these databases.

 If a developer wants to build a Bitcoin-like cryptocurrency, they can, and all of the points re escrow/nothing at stake/counterparty risk would apply to that. (EDIT: Escrow is possible, but not in the same sense Counterparty uses it - you can write whatever script you want and escrow is straightforward, but it would have to make sense within the context of the application.) However, we look at blockchains as a pure, automated database technology - what people want to do with it is up to them. 

When using an interactive application the value is in the use we gain from that application, not the standalone monetary stake represented by the data. Thus the security and trust profile is, and should be, different.

By way of example, our first DApp (which we will be open-sourcing once it’s done in approximately two weeks) is a distributed YouTube with an integrated Bitcoin content incentive payment function. The primary value of such a system is on the entity or individuals deploying it, in that they can use the distributed web to hold their content instead of paying to host it on a server farm. 

In principle any alternative consensus mechanism can be used. One way in which our blockchain design (Thelonious) is proposed to do this initially is through a restricted transaction verification process we refer to as “committing” where certain nodes are granted permissions to add blocks to the chain, and others are not. The GenDOUG smart contract kernel in the Thelonious genesis block (which is on our GitHub repo - as is all our code, as we’re open source!) is where this functionality should be parameterised; we’re cognisant this code is fairly novel so we’d be happy to give you a tutorial/walkthrough (although we will be holding some open sessions in 2015).

In principle, however, any consensus mechanism can be used - as long as the dev drops it into the smart contract kernel. This is the point: we’ve built a blockchain that developers can use on their own without needing to rely on siloed blockchain protocols that are run by other dev teams. 

It doesn’t look and feel like Bitcoin or Counterparty because it wasn’t designed to act like Bitcoin or Counterparty - it was designed to make it easier for people to talk to Bitcoin and Counterparty on their own terms, and (if need be) in one application instead of on separate silos or through a third-party hosted exchange. And we think that’s a pretty good thing!
5

Hi Preston,

This is a very interesting project! Definitely one of the most interesting I’ve seen is this space in a long time…

Re: collaboration, the #MarmotAward probably is indeed probably the best way to get started. The other thing I thought of would be to go the other direction—to have a Counterparty oracle contract [template?] dedicated to publishing the state of Eris DApps (though that might just be part of getting the #MarmotAward). I’m not sure what’s next after that. Your contract language will be 100% compatible with ours and Ethereum’s? If so, we’ll have a lot of common ground right off the bat.

Best,
Adam

6

Dear Adam,


Hello! The contract language should be compatible (our contracts are currently written in LLL). 

Despite the structural differences required by application-specific databases (we front-load a lot of the contract functionality into the Genesis Block), provided a Counterparty wrapper is written we should be able to get Thelonious chains and Counterparty talking to each other. 

CP oracles to publish the state of Eris DApps should also be possible. However, this is where we should link up our dev teams. 

#MarmotAward scope could certainly be extended, but that’s a lot of work for one bounty hunter…! You’ll be pleased to hear the company is planning to award the #PrairieDogPrize, #GroundhogGrant and the #AntelopeGroundSquirrelMeritCitation at some point this year - lesser prizes than the Marmot Award, but high honours nonetheless. I can imagine no higher purpose for any of them than procuring a CP oracle for Eris DApps.

We’re available more or less whenever at #erisindustries on Freenode or, in the alternative, we’d be happy to start the conversation over email with myself and Casey (our CEO) at our respective firstname@erisindustries.com . 
7

Preston,

Sure. Let’s chat through other media. We’re at #xcp on Freenode and here, too: https://gitter.im/CounterpartyXCP/General

Adam