Compact graphs and contract languages

 For a couple of year I played around with th convoluyayion of two semantic graphs that had no loops. I called them compact graphs and they had three operators, grouping operators, and a descend and a branch.

The led to the convolution code over on the right among the links.  The unspecified function was match, how does on pass a node or block it? Via the application specific match between two nodes.

Anyway, that is was contract languages are about except the match is a verification the signature matches that position in the contract. And the contract code is finding the set of signatures that first make it through the contract. So it really is a kind of semantic algebra, selecting the provable path through a finite semantic tree. Proof of stake signatures are on one tree, the contract is the other graph. 

The object model was that any semantic graphs could be represented as a graphical database with four or five method for jump, skipping, inserting, deleting nodes, and matching nodes.

The match function may have its own minor methods to conditional matches. The general idea then is a relaunch, send off a portion of the contract to be resolved and wait for proof of stake results. The main executive was called parse, and it had sub graph capability. 

Under the contracts application, each submission is a request for proof of stake. The output graph just the linear descent of public signatures of the matched parties. The final outcome would be a machine, a machine built for semantic convolution. But the compact graph format fits contracts in the real world, they do have minimal paths, without loops, especially in escrow systems.  One could use an expressive contract language within Parse. Parse is just a provable code the guarantees full comvolution of two finite, compact graphs.

With a reasonably sparse abstraction, finding the main contract structures, and coding for them, we could find an entire Swift contract manager into a Spectre proofed core on a double core processor.  And additionally, the same method works on public chains as long as the proof of stake miners have validation keys.  We get proof of stake and proof of correction, with one language. Mix and match the two forms. A proof of work cache interpreter is a server, the proof of stake is a distributed network. 

But they should match up just fine, the one can 'call' the other pretty easily. Poof of stake requires interested parties to push the contract calling, proof of correction 'calls' for validation from the party, via a proof of stake miner. in the proper order.  Same protocol, different direction.

A proof of stake can be a designated fair traded pit, resulting in price; of an operation on an external ledger with congestion price. Or it might be a validated delivery contract with Fed Ex. Mostly an external ledger validating a claim.