Open questions

Jump to a Question

Compiler

• What is the timeframe for developing a compiler that runs as a contract on the blockchain?

→ Michael Stay (Unlicensed): It's not on the WBS, so I expect it will be sometime after the Mercury release.

• Nash's objection hasn't been addressed: compiler on blockchain that earns can be cloned and offered for less.

→Timm Schäuble: I have no answer on how compiler innovation could be incentivised. I think that there are important cases where cloning does not matter. For example contract deployment out of IntelliJ: They could only allow for a compiler offered by them. Then they would have an incentive to provide good Rholang support.

Block structure

• What hashes are there, and what do they look like?

• What data is common to all blocks?

• What is the size of a block? Can block sizes vary?

• Are there "light blocks" constructable for "light clients"?

→ Michael Stay (Unlicensed): As far as I know, nobody has worked this out yet, except to say that blocks contain formulae describing transactions rather than individual transactions.

Blocks and namespaces

• The common vernacular has nodes processing some subset of the full block chain by way of namespace inclusion. What does this look like?

→ Michael Stay (Unlicensed): 

Clients send transactions to nodes to get them included into blocks.  Nodes are free to reject transactions; one basis for rejecting a transaction is that the names it involves are outside a specific namespace.

• What do we call the set of blocks processed by a node in the case that it's not the full blockchain? Block subchain? [I'll call it this for now] Sub-blockchain? Blockspace? Namechain?

• Is a block subchain a blockchain in itself? If so, what roots a block subchain? If not, how is it verified back to genesis?

• Does segregation of blocks by a namespace relation turn a blockchain into a blocktree, a partially ordered set of blocks?

• Can a single txn involve multiple namespaces? If so, into which block subchain does it go?

→ Michael Stay (Unlicensed): 

Subchains are not necessarily disjoint.  For example, a node may decide to accept any transaction so long as at least one name involved in a transaction belongs to its namespace.

Is it actually a chain, or is it some other structure like a tree?

→ Lucius Meredith: Because we are using CASPER it has to do with the most weight behind it.  Blocks are not just a list of transactions. They are little programs, which extend out to the affected transactions list. THe programs that have consensus around them, they have the most 'weight' behind the proposal - this is stake weight.  The 'fork choice' rule says that when you take a fork, it's the one that has the most stake behind it.  

We're advertising that we don't have to download the entire chain.  How do we figure out what blocks a node has to download?

• - How do we know when a node has downloaded enough to start processing transactions?

• - What information needs to be stored in a block beyond COMM rewrites?  Certainly introducing new contracts; what else?

• - What is the relationship between the storage layer and the blockchain?  Certainly the blocks have to be stored, but there's also talk of storing stuff on the blockchain and paying rent on it.

Lucius Meredith: When a node comes on line, the node has to decide which contracts it wants to serve.  there is a whole bootstrap piece in play here that isn't being discussed.  A node cherry picks amongst the contracts it wants to serve.  Contracts are published under a specific namespace.  There has to be a discovery namespace and a discovery bootstrap.  Nodes are going to serve those contracts that will make them the most money.  'Which contracts are hot? Those are the ones I want to serve".  Then the node can calculate from those contracts what the namespaces are that it is serving.  Once the node has calculated that, then it can draw down the blockchains associated with those transactions in the associated namespaces.  The node can choose to be validator or not, depending on how much money they could make.  The blockchain is the record of the execution of the program.  We are storing the program bytecode, the program source and the program stored execution (trace). 

Ultimately there is a compilation path from names to keys.  The local storage is the local copy of the block chain.  In Special K it is just storing the local state. Where does the block chain come in?  The relationship between the storage layer and the blockchain depends on the type of contract.  The state of the VM will be stored on the blockchain.  In order to gain access to the VM state, a requestor must have access to the blockchain. For this they need the address (key) to the location on the blockchain.    - There is no need to persist the blockchain once we are caught up?  Start from the latest compaction, load the recent transactions and we are ready to go.  We intend on pruning the blockchain, making it easier for nodes to download a much smaller portion of the blockchain.  You have to go back to 'finality' ( the last confirmed finalized transaction )  at a minimum - this is how close to the present you need to go.

To store transactions for longer, a contract must be willing to pay rent  - store it encrypted and throw away the key if they don't pay rent.  We can also implement garbage collection / scavenging.  If a specific namespace remains untouched for a long time, we can move those transactions off, because no one is willing to maintain the data or pay rent to keep it, it goes away.

We will likely need to write system contracts for this and put them out there as prototypes.  Rent doesn't need to be worked out for Mercury, but pretty soon after.

Node operators can decide which contracts they want to hold on to.  

If we don't have rent defined by the Mercury timeframe, we will need to inform folks that their contracts could be erased once Rent is introduced.