22 – SmartContracs: First Presentation of Crypto Conditions

From Komodo Slack on february 19, 2018:  the first public introduction to SmartContracts for Komodo

      Now that the cat is out of the bag, I can reveal a bit more about our plans for blockchain enforced contracts. Just as we use the BTC hashrate as it has the most hashrate and offers the best security and we also use zcash z-transactions for privacy, I believe in adopting standards whenever practical.

To that effect, in the most unlikely place, we find a very interesting proposal from Ripple called “interledger protocol”:

https://interledger.org/rfcs/0003-interledger-protocol/
https://tools.ietf.org/html/draft-thomas-crypto-conditions-03

      Ignoring the source of this idea (it is now being worked on by many projects) the idea of an industry standard for blockchain operations is a good one and why reinvent the wheel if one already exists?

The Crypto Conditions (CC) is what extends the bitcoin protocol to allow much more flexible contracts. BigchainDB has good explanations of what CC can be used for. We commissioned a pure C implementation of CC by the author of BigchainDB implementation and it is now available as a standalone, but also we have it integrated into the komodo source base and activated via -ac_cc=1, have to be careful as it will create a hardfork so it is only for test chains for now

It is still early, but a CC transaction was created and spent on the CCTEST chain, so now that we are starting the test phase, I want to open up the process so people can get used to it and help out as they can. @fullmoon has already made a connector for the ILP integration, though that will likely need to be updated and I have to thank him for identifying the ILP and CC as possible solutions for blockchain enforcing contracts.

There is a lot of documentation on ILP and CC (the advantage of adopting a standard is you don’t have to write much documentation!) so you can come up to speed with it sooner than later.

Of course, I came up with a way to integrate all this with real time betting and games, I wrote a draft of: “A generalized architecture for real time decentralized applications with blockchain enforcement of arbitrary statemachine evaluators” but it still needs some parts completed, so it wont’ be ready for a while yet.

For those not in the #chips channel wondering what a statemachine is:

https://www.quora.com/Why-would-one-use-a-Finite-state-machine

Peter Webb
Answered Jul 20, 2015 – Author has 4.9k answers and 2.1, answers views
It’s worth pointing out that all real computer and programs are finite state machines (FSM), because they have only a finite amount of memory available (as opposed to Turing machines which have unlimited storage).

      This is the rough outline for how KMD platform will be able to match ETH tech, without ever having to deal with massive gas prices or hours of confirmation times, as each app will get its own parallel chain (appchain?). No DAO disaster to bring the entire ecosystem down, each appchain is free to selfdistruct without affecting anything else.

I realize the above is a lot to take in and will take a bit of time to absorb and it isn’t easy to understand. That is why we have the marketing peoples who will need some time to do the same and figure out how best to present this. But for those that had doubt that KMD could ever match the ETH tech, I think that is well answered by this.

jl777

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s