Dario_o Posted March 13, 2019 Share Posted March 13, 2019 (edited) I really hoped you noticed this question from @stuartXRP, because I'd love to understand how Codius is much better than other blockchain based smart contract platforms. On 3/8/2019 at 12:42 PM, stuartXRP said: Can you see Ripple going after the derivatives market with Codius in the future, was it ever discussed when you were there ? I understand the peanut butter manifesto, but it would be great to have two slices of toast with peanut butter on. Bob's Note: @stuartXRP You asked lots of questions in your post in the original thread. I'll address the rest in a separate thread. Codius is really something huge, but maybe a little overlooked in your forum post, at the moment the only (very) interesting thing you wrote about is this gem Quote But just to get you started, you probably know that Stefan, Ben, and Peter founded a new company called Coil. What you probably don't know is that the name Coil was Ben's idea. It is a contraction of "Codius" and "ILP". Edited March 21, 2019 by BobWay stuartXRP and rippCurrent 2 Link to comment Share on other sites More sharing options...
BobWay Posted March 21, 2019 Share Posted March 21, 2019 (edited) On 3/13/2019 at 6:37 AM, Dario_o said: I'd love to understand how Codius is much better than other blockchain based smart contract platforms. Let me tell you how it is different by giving you a little background. I'll leave "better" for others to argue. I describe the "crypto contracts" phenomena as having happened in four technology phases. Bitcoin UTXO scripts specially written to interpret make more than just a single signature. Ethereum on-chain contracts which execute within every server node. Codius contracts which execute off-chain contracts. ILP two-phase commit for money. Edited March 24, 2019 by BobWay SquaryBone, jlr, Dario_o and 1 other 4 Link to comment Share on other sites More sharing options...
BobWay Posted March 23, 2019 Share Posted March 23, 2019 Phase 1: Bitcoin on-chain scripts The Bitcoin "Ledger" uses an unconventional accounting model referred to as "Unspent Transaction Outputs" (UTXO). What happens is that every bitcoin transaction consumes one or more "inputs" (hence spending them). And the same transaction generates one or more "outputs". So just to be clear, the inputs to one transaction are outputs from one or more previous transactions. Once you've spent an output, you must be prevented from spending it again. The is bitcoin's famous "double spend problem." Note: Double Spend is bitcoin jargon. Bankers never use that term. In banking the same concept is called, "Over Drawing Your Account." Or even a bit more nastily, "Bouncing a Check." All it really means is you can't spend money you don't have. Now an unspent transaction output is like a little safe of bitcoin tracked inside every bitcoind node. Each safe is locked by a short computer function called a "script". If you want to open the safe and spend the bitcoin in the UTXO, you must submit the correct input to the attached script. The script processes the input and if the function returns TRUE, then the BTC is yours to spend. The default script takes a single transaction signature as input and validates the signing key against the bitcoin address the output was delivered to. In general, the default bitcoin output script is not generally referred to as a smart contract. But it is possible to substitute that default script with one of your own. Maybe something "smarter" like a script that requires multiple signatures for example. These scripts began the talk of smart contracts. However, they are limited as designed. You can't program a loop, and all bitcoin scripts are passive. Meaning they only respond AFTER some external agent (think human) submits a transaction to the bitcoin network. So bitcoin scripts can't monitor outside sources for data. They have to wait for someone to give them something to do. Odiseo, jlr, ChazzCoin and 1 other 4 Link to comment Share on other sites More sharing options...
BobWay Posted March 23, 2019 Share Posted March 23, 2019 (edited) Phase 2: Ethereum on-chain contracts Placeholder. Still working on this post Edited March 24, 2019 by BobWay ChazzCoin 1 Link to comment Share on other sites More sharing options...
BobWay Posted March 23, 2019 Share Posted March 23, 2019 (edited) Phase 3: Codius off-chain contracts Placeholder. I was writing this in answer of another question, but I'm going to put it here as well. Expect me to rewrite this for flow, after writing the section on Ethereum --- Codius itself is NOT a blockchain or storage mechanism at all. It is a way for non-blockchain cloud hosting providers to run verified code. It is also a mechanism to pay those hosts for their continued execution of that running code. The idea is, I could write a useful piece of software functionality, and upload it to one or more cloud hosts to operate it as a service. I would then tell other interesting people, WHAT that code is (the source code) and WHERE that code is running. The host's job is to verify that the code they are running as a services is exactly WHAT I told you that code is. Note: I didn't mention blockchain or data or transactions in this whole description. That is because Codius is more generally useful than that. So what's to keep the cloud hosts from running that code forever? Well, money of course. And say as the author I don't really get as much benefit from the code as everyone else, so I'm not interested in paying for the rest of my life to keep it running. So the Codius concept allows anyone who finds the running code useful, to send payments to the host, or even contract itself, in order to keep it running over the long term. And when nobody sees enough value in the running contract to continue paying for, the contract dies automatically. Verified code means that the author writes the code and hashes (digests) it so that everyone who wants to participate knows exactly WHAT (the rules) they are agreeing to participate with. Then the question becomes, WHERE are those rules being processed. This is the fun bit, Codius allows the author to run the code on one or more cloud hosts simultaneously. So if you want to use my service in the cloud, but you don't really like or trust Google, then you could use the same service on Azure. And if that service isn't running on a host you like, you could even copy it and put it on wherever Codius host you want it to be. The verified code aspect assures everyone who trusts your choice of host, that you didn't tamper with the code during the move. If the author finds it useful, those code instances can also work together through their own consensus mechanism. This assures robust operation through redundancy, and also creates a peer-to-peer network of identical running contract instances. The author of such a contract network, could write code that monitored how many instances were running and where, and potentially launch replacement instances whenever a hosting provider went down. This is not functionality in the core of Codius. But it is functionality that Codius' consistency standards make possible. The last really cool innovation of Codius is to realize that it is really hard to give a cryptographic "secret" (private key) to a contract running on a blockchain. Since anyone can run a blockchain node and inspect both the code and the data, any secret would be quickly unmasked. But while Codius code instances are all guaranteed to be exactly the same, each instances data does not have to be. And in fact, that data doesn't have to be public at all. This can be really helpful in protecting secrets. Now at first, giving a secret to any Codius host seems like a dodgy idea. But through the magic of cryptography, you really don't have to. Using the peer-to-peer collaboration described above, you can give each instance a "share" of the secret. And only by working together can they sign and issue valid transactions. So say contract shares are running on, Google, Amazon, Azure & other hosts around the world. An attacker would need to compromise a significant majority of the instances and capture their respective secrets, in order to sign their own malicious transactions. Secrets can be shared using multi-sign (m of n) transactions. Or they can be share through threshold signature magic. Neither of these techniques requires reconstructing the signing secret on any particular node. --- I'll write more here about things off-chain contracts can do that are inconvenient for on-chain contracts, soon. Edited March 24, 2019 by BobWay SquaryBone and ChazzCoin 2 Link to comment Share on other sites More sharing options...
BobWay Posted March 23, 2019 Share Posted March 23, 2019 Phase 4: ILP "two-phase commit" for money (80% of contracts seemed to implement some form of value "escrow". This was often done in order to synchronize bi-direction (give and receive) business transactions. ILP implements this process natively, doing away with the need for many, many proposed "smart-contracts". Placeholder. Still working on this post Link to comment Share on other sites More sharing options...
BobWay Posted March 23, 2019 Share Posted March 23, 2019 I'm releasing this thread even though it is still a work in progress. Contracts are a topic lots of people have asked about, so the book club needs a thread to start the discussion. I'll finish the background as I have time. But feel you have to wait for that in order to ask questions and start the discussion. vertical_awareness, Dario_o, Odiseo and 1 other 2 2 Link to comment Share on other sites More sharing options...
Sukrim Posted March 23, 2019 Share Posted March 23, 2019 4 hours ago, BobWay said: Double Spend is bitcoin jargon. It's more of an "electronic money" jargon, or computer science jargon. That's why the term is also used in the abstract of the whitepaper written by Satoshi. Looking forward to the descriptions of other systems, like Ethereum. Link to comment Share on other sites More sharing options...
Recommended Posts