Think of on line purchase of lawn mower. Both a purchase and a sipping contract, two step.
Shard it. The user agrees to the two step, purchase price, and if not delivered in two weeks call customer service. So the user locks purchase price to a shard, and the contract is kept with the shard, on the short chain. us all parties along the chain can validate each portion of the contract for conditionals. All three accounts; shipper, buyer, seller, are reconciled. One way or the other, he exit takes a known path out with some congestion pricing absorbed according to contract. Each party represented by their own trusted miner, generally an insurance company.
Contract completions validated by secret pass code by the sender, so it is a one shot to validate and checksum that step in the contract, and post it in the shard. The shard i collapse internally on completion, there is no gain from spying except to attempt to recover secret pass code. So, baring secret code heft, this is spectre safe, on a public ledger. That s some good stuff. The key is to keep local proof of stake on a local finite chain.
Contract language becomes shard language. Ledger swaps, entry, exit, fails to deliver exit, trusted miner, timeouts, count limits. This should all be a microcode attached o the ledger, an I think the original BTC chain had these contract code. But they had no sharding method. Ti propose sharding is the perfect contract expansion system, provable to observable market risk.
No comments:
Post a Comment