Communications: Open Questions

Owned by Medha Parlikar (Unlicensed)
Last updated: Sept 15, 2017
2 min read

 You mentioned that communication in order to create the blockchain is different than communication on the blockchain.  There seems to be a need for at least four kinds of communication:

  • Low level internal peer-to-peer communication
  • Contract to contract communication via the blockchain,
  • Contract to contract communication OFF the blockchain,
  • Contract to world communication

Can you comment on how you envision these fitting together, at what level Casper is to be implemented and what levels it enables?  Where does the data abstraction layer fit?

→ Lucius Meredith: The only one that causes security concerns for people is the third.  Contract to Contract OFF the blockchain.  If those 2 contracts mix on-chain and off-chain state- you must deal with trust issues.

We want to write the CASPER contracts for the compiler that is NOT blockchain aware.  The behavioral types have to provide us an in-place

What we want is to have the behavioral types for the contracts provide us with an in place proof of correctness.  The types specify how these contracts fit together, what they are supposed to do and the properties they are supposed to maintain.  The fact that they type check is proof that the contract was authored correctly.   Contracts are given behavioral types that map to an expected behavior.  Upon compilation, the contract will be checked against the type.

The blockchain semantics doesn't happen until CASPER is running. 

We may need to shuffle CASPER code down to lower system levels to ensure performance.

When you say things like 'socket communication at the contract level' - where does it run? 

→ It's a channel type - ex: TCP.  you will set up all the bind functionality at the low level (built by Chris)

For communication that does not go on the blockchain - where does that run?  The contract is executing in many different places at once, and you are expecting input on a socked in many different places at once, you get the input where the operator is interacting with the thing, or where it expects the input to be.

 → Now you can see the security issues that are present.  In fact, there are resource exhaustion issues in play here as well.  There's all kinds of issues.  The safest kinds of contracts are ones that don't have these issues.  But there are business requirements to do exactly this.  

You need business data - Options?  Load all the data on to the chain?!  So there needs to be contracts that are 'trusted' - they run in these kinds of pseudo-trusted ways.  You have to have capability to trust some contracts.  

→ Answer How do we do this?  Only 1 of the instances of the contract is going to pick up the signal.  One wins, but they all try.

→ The higher level notion of channel could be used to mix blockchain and non-blockchain channels.  You could provide a contract that aggregates a bunch of non-blockchain behavior into a channel.  And that channel could be mixed with on-chain channels. If you are willing to subscribe to the properties of the channel behavior of the non-chain channel.  Something like bit commitment or oblivious transfer, by amortizing you can get a continuous security parameter.