28 – SmartContracts: More Questions, UTXO, Languages, etc.

From Komodo Discord, august 2018:

IdeasByKlo: What makes utxo model unsuitable for smart-contracts like on Ethereum? Or in other words, why must Komodo currently use Crypto-Conditions to develop smart-contracts and what are the limitations? Forgive me if this question is not even worded correctly. Is it that utxo model can only support value transfer from the contracts whereas smart-contracts on Ethereum can handle state changes?

jl777: Ethereum is a balance based system, so it doesn’t really have utxo. Bitcoin protocol is based on utxo, so it has utxo. Crypto-Conditions is a proposed IETF standard, Komodo is the first to get it live into a working blockchain. Komodo doesn’t have to use it, but since we made it, it seemed like a good idea to use it.
CC contracts are Turing-complete and as such it can handle state transitions or anything else that is needed. I think the differences are really more internal than anything else. I did make assets, faucet, rewards and dice CC contracts to demonstrate a hint of what is possible. If you can describe a contract and what state changes it needs to handle, I can write a CC contract to implement it.
Turing-complete means anything that any other Turing-complete system can do, can also be done

IdeasByK: Thanks. To further my understanding what are the differences between CC on the Komodo-platform (not Komodo) vs Ethereum? I was under the impression there were still some limitations for CC on Komodo 2.0, but trying to get up to speed on motivations behind CC

jl777: Crypto-Conditions is a proposed IETF standard, so supporting it is a good thing. We enhanced the baseline CC with a utxo smart-contracts layer on top of it. It is Turing-complete. It runs native code compiled into komodod, that means there really shouldn’t be any smart-contract that can’t be written. The motivation is to do smart-contracts efficiently

IdeasByK: Got it

jl777: As far as how is it different from Ethereum… it seems it has very little in common

IdeasByK: But the end use cases are all supportable regardless of CC or Ethereum

lukechilds: I think I remember hearing before about language bindings for CC
is that correct? If so, how would that work? Would you be able to implement CC smart-contracts in high level languages like Python/Ruby/JavaScript etc. by importing a CC binding library or using an SDK?

Mylo: Yes, that’s correct @lukechilds. Currently only C++ (maybe C as well?). There is another dev working on Python bindings for another set of features, not sure about py-cc at this stage. I’ll ask next time we have a meeting, maybe this week maybe next.
@IdeasByK where there is a reference CC smart contract called “dice”, it is actually an implementation of a popular pattern: “challenge/response”, so if you have another type of challenge/response scenario (e.g. I have a rewarding global math quiz for children game), this is where I’ve been told to look as my first port of call re: the challenge/response mechanism. This is 1 of the 4 initial reference smart-contracts, the other is a simple faucet, another tokenized exchange, and lastly rewards for locking up coins (like a masternode, staking style of thing – which I have to be vague about because I haven’t looked into it yet). James is going to start a new round of smart-contracts development soon, extending on initial reference catalogue

lukechilds: This is really exciting but I can’t quite wrap my head around how it can be integrated into a higher level language. So for example if I was using JS with JS bindings, does my JS code end up being compiled down to some kind of CC compatible byte code? Or do I actually run a Node.js server and calling the CC lib functions is making some kind of CC tx and broadcasting it to the Komodo network? Or something totally different?

Mylo: Let’s just stick to CC for now, not implementing server (nodejs etc.), CC is binary (hex) representation of data. So 0x80 0x02 0x55 0x55 is an arbitrary value, is always that in hex. It is interpreted by the CC protocol as meaning something. For this arbitrary example, 0x80 might mean EVAL function, 0x02 might mean the length of the EVAL function and 0x55 0x55 is the value of the 2byte length of the EVAL function. This is portable across languages because in bytes, it’s the same.

The EVAL function/value is the ID of the smart contract: e.g.

https://github.com/jl777/komodo/blob/jl777/src/cc/eval.h#L40

are the currently defined catalogue of smart contracts. As for different languages, not sure how it would work exactly. Maybe you compile your py/js/go languages down to a compatible shared object that can be loaded by komodod at startup (or with helper rpc command to load said library, like importwallet). This part is just hocus-pocus-mylo-babble. You need the jl777 and ca333 brains to think this one throug. Draft standard:

https://tools.ietf.org/html/draft-thomas-crypto-conditions-04

It’s described using ASN.1 notation which is used in SNMP (network monitoring mibs descriptions) and HL7 medical application protocols. In both those cases, SNMP endpoints are embedded into equipment (usually low level language) but at the same time applications (and app servers like jboss etc.) can be MIBS for network monitoring information. HL7… I know less about, but it’s so an X-ray machine can talk to the application running on a DRs’ computer to display the image which is transported from device to file storage, from file storage to application etc. and then a related workflow is also tied to HL7 protocol stuff so the time sheet application can bill the patient record accordingly. And similarly for nurses doing the rounds giving medication etc.
So similarly, once bindings to Komodo’s implementation of CC is available to other languages, we get lots of cross applications, cross blockchain possibilities…. (with engineering work)

lukechilds: Very exciting stuff, yeah… I think I’ll need to see an example app to fully grok how it all ties together

Mylo: Contract side is one thing on the server, loaded into komodod. App side is accessible via rpc.

e.g. faucet rpc:
https://github.com/imylomylo/komodo-rpc-lib/blob/master/src/faucet/index.js

but the contract is:
https://github.com/jl777/komodo/blob/jl777/src/cc/faucet.cpp

faucet.cpp compiles to 0x22 0x50 0x……..

Your go/py/js serverside stuff smart contract which interacts with blockchain/wallet/transactions/utxo compiled down to 0x22 0x50 0x……. can be loaded by komodod. It’s the same bytes. Just at the high level was written differently, compiled down.

You provide an rpc to your smart contract functions.

App developers use your rpc and smart contract to write apps.

If that makes things a bit clearer:

https://github.com/imylomylo/komodo-rpc-lib/blob/master/src/faucet/index.js

https://github.com/jl777/komodo/blob/jl777/src/cc/faucet.cpp

You don’t run a server along with komodod – there is no interactivity with an external server. Your smart-contract just was written in a different language for your own preference, and compiled down to bytes (that could have been written by another language). “Byte code” is the same. The smart-contract interacts with blockchain data/tx/etc.

If you are thinking to poll an external service for data to input into contract stuff, then which node would poll? Which node would insert into blockchain? This is not the (ideal) architecture for a smart contract blockchain app. The smart-contract relies on blockchain data, so you’d need to find another way to get the data into the blockchain. If you publish too many times into the blockchain then, which is the authoritative data? How large would the data bloat the chain. Your options for this line of thinking is either via oracle network or something.

That’s my 2c. Sorry to flood channel

lukechilds: Oh wait, I think I get it, so I can write my CC in JS e.g an echo function, using the JS bindings, which compiles down to HEX, which I then broadcast to the Komodo network (as a special transaction?). Then I can build a web page that makes rpc requests to a local Komodo daemon to interact with the CC. And the rpc request would be something like {ccaddress: address, command: ‘echo’, value ‘helloworld’}. Something like that?

Mylo: Yes something like that. Except first step. Yes you compile down. Yes you then have your node with the CC smart contract you wrote. But other nodes won’t have it to reference except the tx they’ll know, but won’t know anything to do with it because they haven’t got it installed in their node. Each node then needs your special smart contract. Might not be relevant to the Komodo main chain to know about LukesJSEchoCCSmartContract (I mean it could, but unlikely), but some assetchain use case your smart contract solves can load your contract at start up – and decentralize/trustless verify the tx on it’s own.
And yes, you make an RPC available for app developers to interact with your smart contract.

grewalsatinder: I’d instead would like to use/try SPV + CC + WASM in web browser.
Coding WASM in GO. What is the reason utxo based smart contracts haven’t been thought or done by others in industry and what made Komodo’s implementation different as comparison to others?

Mylo: CC layer allows for smart-utxo. Bind them to previous transactions (e.g. at creation time) and other types of relationships is my guess. All on-chain. So where you may have had two tx in the past and been able to make an app that behaves in a similar way, there was no blockchain binding – only an app that could mimic a what-if-we-could-bind-these-transactions-together-with-some-rules. We now have these rules (conditions) on chain, instead of some random app developer.

jl777: Currently the CC contracts are done at the source level, it is linked in and part of the komodod codebase. Now, it would be possible to make some sort of dynamic linked library to include external code, this library would have the identical code functions as the current CC contracts. Look at faucet.cpp it is 100 lines and not very complex at all.
So whatever language that can create compiled code that can be linked into komodod, those are the languages that can be used. I wouldn’t recommend interpreted language and the model now is to make a CC contract that can spawn new instances of it via rpc calls. And to limit any repetitive actions and rather be transaction invoked to get runtime. So for assets CC, you do a tx that locks coins/assets into a special address and the other party spends that tx to complete the trade.
Let us not get too abstract.
Let us stick to specific questions on how to do some specific thing.
I think that will then make it much clearer how it all works.
Start by reading faucet.cpp, then rewards.cpp, then dice.cpp and assets.cpp if you are ready for that level of complexity.
Probably we need someone to make onboarding doc to allow a new developers to come up to speed, however it will require knowing how utxo work. So if we can find pre-existing docs about utxo, a new developer can start with that.
Once you understand utxo, then it will become much clearer. If you don’t, it will just be confusing

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