Implement Budget DSL in terms of Call and PageTable

[aeyakovenko]

• Implements a PageTable which is a data structure for mapping PublicKey -> Page
• Defines a ContractId, which is a PublicKey of the contract
• A Page defines a memory region, and holds a balance of tokens
• Pages can be assigned to a Contract. This is conceptually similar to mapping physical memory to a process.
• Runtime will pull up transactions and execute them in parallel if they have no overlap
• top bench performance for simple spends is with a thread group of 4-8, and around 500ktps. (more optimization ideas are possible)
  Another way to think of the model is a single address space OS with memory protection for processes.

decisions to be made

• do a signature check like current bank, or use a version in the spenders Page structure?

A version in the Page structure means that a spender has to know the current version, and only a single transaction that matches it will be executed.

if we use a version, it nearly impossible for the spender to asynchronously post a bunch of transactions and only retry the failed ones. Spender would send transactions with version 0, 1, 2, 3, 4
if 2 is dropped or arrives out of order, 3, and 4 are likely to be dropped as well.

This is how I currently implemented Page, but I am having second thoughts. Especially since asynchronous signals will not be able to predict what the version of the Page is.

• Parallelize blobs, or process multiple blobs in parallel but each blob sequentially.

PageTable locks memory per transaction, that means that the blobs output is parallelizable for the blob.

But performance is better when we have multiple blobs of transactions processed at the same time. this means that blobs can lock memory for the blob, and process transactions in series. maybe we have different queues, for contracts that are expensive or cheap to serialize?

[garious]

Why do you implement Transaction in terms of Call and not Instruction?

[aeyakovenko]

@garious Transaction was the interface that we used over the wire. I think we can remove it and just have Instruction as the bank contract specific user data.

[garious]

@aeyakovenko, I'm just to get my head around how this should relate to @carllin's work to support multiple instructions in: #602

[aeyakovenko]

@garious The main change is that the to address needs to be supplied for the state transitions in the contract. Because the state is stored in the memory that belongs to the to page. So if you want to modify multiple contracts at once, you would need to pass a set of keys, which Call supports. All the pages will get loaded and passed to the contract method.

[garious]

@aeyakovenko, close this PR since it's coming in as separate smaller PRs?

[aeyakovenko]

#953 is taking over this pr