Tweet ghim
Verification-Centric Chains, Common Knowledge Machines, and Intents
Verification-centric blockchains outsource the computation/generation of transactions to off-chain agents ("solvers").
But a verification-centric chain is only as good as its verifier (the VM). You can judge a verification-centric chain's programming model by asking these questions:
1. What verification conditions can be expressed?
2. How easily can a solver understand the verification conditions, so they can treat those as a goal/problem to solve?
3. Are solvers afforded with some level of interoperability, or must we forsake trustless interop at the compute layer just because it lives off-chain (in contrast to compute-centric chains like Ethereum, where any smart contract can at least attempt to interact with any other)?
UTXO-based chains are the OG verification-centric chain. eUTXO / generalized utxo chains improve on the first of the three properties above: expressiveness.
In generalized UTXO chains, the kinds of verification conditions that can be expressed are comparable to the kinds of computations that can be expressed in a compute-centric chain.
But two challenges remain:
1. Semantic opacity: those verification conditions are not expressed in a format that a solver can easily understand: a developer has to manually implement a new solver that can understand and compute over the various verification programs it wishes to integrate with.
2. Reduced interoperability: Computation happens off-chain. So "integrating" with a protocol means generating transactions that fulfill that protocol's verification conditions within the context of a larger transaction. But that means that every protocol & app dev has to re-implement the business logic of every protocol & app with which they wish to integrate.
@khalani_network addresses these remaining challenges.
1. Semantic transparency: We create a new programming model that is semantically transparent. This means that the semantics of protocols & applications are discoverable and understandable by solvers. The most obvious way to do this is use a declarative model. The problem with a declarative model is that it is too rigid: it adds transparency at the expense of expressiveness, limiting the kinds of systems that it can support. Adding imperative features would address this, but it would do so at the expense of trustlessness and semantic transparency.
2. Intent-based interoperability: With a sufficiently expressive, semantically transparent model, intents become the most natural primitive for trustless coordination between off-chain agents because they can establish a shared & agreed upon set of expectations and understanding of how to interact! I.e., they can establish common knowledge, which is critical to facilitating coordination of any kind.
Khalani's VM, the Common Knowledge Machine, provides the means for solvers to coordinate around shared goals on-the-fly. Sort of like machine-to-machine MOU's, lol.
This has many consequences, but I'll describe just one for now (this is an X post, not a whitepaper, after all): the wild world of off-chain software becomes far less brittle, because APIs get replaced with ALIs (Application Logical Interfaces) and conformance to these "specs" is guaranteed.
English
