Sunday, November 1, 2020

Consider this contract

 I buy a thing from you and will pay you a number of the price is greater than four.

Conditional test and payment in bearer cash are direct, no external transfer.

Then you tell me to put this on short chain. The contract is chained, buy the thing at market price, then perform a ledger swap at market price.  I can have only one market access per coin tos, this is a lot like portfolio balancing. Each conditional that cause a contract to exit the instruction cache is a contract held under timeout and erased from local memory. That can happen only once per cache instance, wqhich mus be one contract link.

If all my external accesses have measurable but uncertain queues. The expanded contract is a directed graph without loops. If external access comes with fails to deliver probabilities, then the entire chain is proven down to customer judged market risk.  There is no condition in which a fail to deliver can come from two conditional sources without being resolved. 

Contracts compile to provability

This is really a network protocol design problem. Each contract link executes on network protocol with a positive possibility of legal failure. These are the critical count and time limits. So a compiled contract contain includes the define sub contracts for various ledger swaps. You would have a Swift include a Btc include. These include have the standard account ledger methods and process the critical time and cunt limits.

You compiler treats bearer cash like local variables. The contract may or may not specify an include for a local short chain ledger, but that is just a global memory manager under congestion management. It is cleared on entry and exit.

All of these possible and each unique trader module provable on its own. The compiler need only check all the fails to deliver outcomes as separate exits from any contract segment, likes its position in memory as a function. It really is an adaption of the compiler technique.

Every entry to a contract link assume market balanced accounts coming in. A fails to deliver reverts to that point.  So provable contract have congestion exits at balanced points, and each contract link is a balanced swap.

Consider the condition, I buy thing one, then check market price for the next step. The next step requires I pay you, but I am motivated to execute a fails to deliver.. But the compile catches this, as accounts are not balanced in input. It is an expression optimizing problem, the compiler allocates local bearer cash to old the five dollars up front.

The the compiler requires may also have a hold from the previous step.  This is equivalent to telling the prior ledger to hold some ledger account for time and count, the contract will shard this account to hold a conditions on the next steps.  In the computer world whit is tagging a memory object so it is not returned to free chain.   Then function calls can all be made spectre compatible. Balanced account in and out.  There will be an equivalence to regular compilation but have peculiar call set up and return to meet spectre condition in the cache.

All ledger need two congestion exits:  Hold an account for time and count and  Hold for reversal for time and count. Count here is waiting steps in the queue. The second is for general ledger swaps, the former for short chain sharding, making change off the master ledger.  A contract enforcement is about keeping object space conserved,where objects are accounts. Each account has assets in memory, bearer cache memory or public ledger memory. Each memory manager stale at the into to a contact link.  Each party in the contract has their total assets balanced across the three types of accounts.

In the compiled state,each link is a transaction entry in which a ledger swap is performed,between two parties, where we include local cache memory as a ledger.  Local bearer cash may be held by the pit boss, or contract boss in this case. But the cache is still a ledger. If the pit boss fails,the last known stable point is known.  But recovery only goes back to the last market access. That contract link had a fails to deliver,work that stable exit.  The pit boss fails to deliver on local cache accounts. Those are had numbers,pit boss liquidity and the parties fully restored, to the balanced exit point.

We already have some ledger protocols, order confirmations comes by mail almost immediately. Plus shipping updates. We have confirmation codes, we have cancellation periods.  All of these construed as ledger protocols and we define the standard ledger APIs for contract enforcement. 

Contract clauses do not have waits, but they can leave a trusted miner to watch for a market condition, but that trusted miner can be timed out with fails to deliver. ll contracts resolve.   So party one put up ten dollars in bearer cash. There is the external wait on a market event from another contract,essentially.  The external trusted miner return with a sales contract, the stock seller has an account on the same price ledger,the contract manager then executes a ledger swap, on two ledgers, the stock and the money.  

How do we know a ledger is valid?  Say, someone runs a landlord/renter ledger. Well the landlords needs to register her biometrics so the ledger operator can match owner with public records. hen the owners are subject to fails to deliver on double rentals. That means some insurance and legal work for the property owner.   Thee are trusted miners who handle fails to deliver,they are called lawyers.

The contract compiler is essentially placing a memory fault at fails to deliver. And insuring balanced entry for a restoration point.  The cache locals are never global beyond a cache swap. They are one the public ledgers and safe. So, the segment occurs only once and resolves,there is no spectre vulnerability from swaps.

No comments: