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.

I wonder how many people had to watch and sign off on this video. Every character is loathsome, depicting rather accurately an archetype that is increasingly common in our society. Was the goal to repulse? Or have the makers fallen so far they were unaware that the family portrayed here is weak; is void of mutual respect; is starved for values. The father is the ultimate antagonist, but so pitiful that it takes a moment to recognize that. The dog is, ultimately, the protagonist.

And thus we observe the return to verification-centric architectures (realized and idealized by UTXO chains like @NervosNetwork and Bitcoin). Whether by means of cryptography or other forms of succinct verification, the concept is the same: don’t replicate globally what need not be replicated globally.

Shut up and read it

I would love to be a plane ticket. What it’s like to be a plane ticket is an even more intriguing question than what it’s like to be a bat. How much $$ to be a plane ticket?

Serafim is doing really cool work at the intersection of LLMs and various forms of formal and semi formal reasoning.

Confidentiality is better than publicity for those who need informational discretion. Privacy is better than confidentiality for those who need informational isolation that doesn’t depend on the discretion of another.

Engineers and technical folks can fall into the trap of thinking predominantly at the implementation level, ignoring the conceptual model of which the implementation is but one *instance*. Incidentally, the latter called “tokens” in philosophy (what a versatile word it turns out to be!). The former are called “types”. Dont miss the forest for the trees… or better yet: Don’t miss the types for the tokens!

I too enjoy So Krate and his thought provoking arguments on occasion. I particularly enjoyed when he proved that knowledge is impossible because things change and therefore we are all entitled to our own, equally (in)valid opinion. On account of nobody reading what I post, I’ve decided not to explain that this is a joke. I am aware that explicitly labeling it a joke does, arguably, count as an explanation. But in my opinion it does not. Per SoKarate vis a vis playdough, that is sufficient.

Three “shower thoughts”, if you will, about AI business models past and present: 1. The model is not the moat (or shouldn’t be). General purpose models do “eat away” at specialist use cases in the sense that they do render specialist products “obsolete” in capability. But capability isnt the only thing consumers care about. In fact, as the industry matures, capability is simply taken for granted. *If an AI business would be killed by offering a bring-your-own-keys option to consumers, then it’s going to be killed at some point because it is either a model-company OR it depends entirely on functioning as an intermediary and applying fees on top* 2. Product offerings are growing in breadth as model providers and downstream solutions try to become the everything app. This approach makes the immediate experience superior for the consumer but it also fails the consumer… if the everything app is great for x, y and z but horrendous for w, using a second app whenever you need to do w is painful. The major cause of this consumer friction is that data portability is still not solved. Interop standards are getting better but interoperability is structurally *aligned* with data fragmentation: interop wouldn’t be a compelling problem in the first place if a person’s data were properly portable. Why is data not portable, then? Well, the personalized experience of using AI chatbots is due to that data. Entrenching that data within a specific provider *is* what creates stickiness because the switching cost only grows with further use. 3. As AI becomes entrenched in business and personal operations of a growing number of users, specialist systems designed from the ground up for that business or that person will always be superior to general systems. The general systems are great for rapidly building such specialist systems. Even faster than building them is offering well polished, heavily customizable platforms and apps… But specialist systems will come with diverse and bespoke requirements. Either platforms and apps allow for heavy customization & BYOK *or* people will resolve to build their own using the models offered by the same orgs that are trying to be everything apps. This is all to say: AI is a unique software because people can use it to free themselves from vendor lock in. For example, at @khalani_network we have multiple custom built internal tools, some developed by non technical team members, that outperforms the best SaaS equivalent… And yet, by offering such freedom, model providers become the next incumbent. Their business models today largely revolve around fee models that don’t make sense for the consumer or imposing constraints at the model level that aren’t strictly necessary for the nature of their product as such. P.S. TLDpR (too lazy, didn’t proof read). Unsurprisingly this also means too lazy to add a TLDR. Just ask @grok if you need one

Have said this would happen for a long while now. Hook usage inevitably converges to a few well know, well reputed hooks. This is not because people don't want ultimate flexibility and diversity of use cases. Rather, it is because the risk and cost of taking advantage of all hooks is prohibitive. The root cause is the programming & state model itself: the Account model. In the Account model, giving users more power requires that users take on greater risk and grant trust to a larger circle of operators. Hooks introduce an entirely new level of extensibility-through-programmability. It's not just "an" approach: it is *the* approach in an architecture dominated by account model. Here is the conceptual model: 1. Users accomplish things through transactions, which can optionally be calls to a piece of code. 2. To enable users to accomplish more kinds of things, developers build more pieces of code. 3. The user's goal is implicit in the business logic of the code they call. 4. The user is unlikely to have performed an in-depth audit of all the code that executes as a result of their transaction. That asymmetry is a recipe for disaster in an open minefield of permissionlessly deployed code.

Jim’s work over the last few years has been truly formative for me philosophically and beyond. In the later stages of my own studies and research, I reached a point where philosophy of mind seemed hopeless. There seemed to be no way forward: at the end of every potential path resides miracles, magic or paradox. The Mind, it seemed, was incapable of explaining its own existence or provenance. It is the most perplexing phenomenon in the universe and also the only thing capable of *being perplexed*. For all its intellectual and reflective power, and all its impressive capacity to comprehend the “world out there”, that success does not transfer when it takes *itself* as the object of inquiry. Jim’s work lays the foundation for a new way forward. A way forward for philosophy that does not demand of the philosopher that she abandon the very intellectual virtues that make her a philosopher as such. This latest work acknowledges the difficulty of the philosophical quest explicitly. Even more, it takes that difficulty as a crucial clue and asks: what if our apparent inability to find the answer we’ve been looking is itself part of the answer? If you happen to be one of those entities walking around with a mind, you should use that mind to read this book

Today is the day many will realize that their AI-native companies (in which AI is deeply integrated into normal operations) is not AI-native if it is entirely dependent on frontier labs’ models. Two problems: 1. You need compute resources that aren’t vulnerable to such a vast set of unknown externalities 2. Your data should be portable. Models and memory ought to be de-coupled. All of the knowledge (including preferences, custom prompts, custom skills, chat history, and even your connectors) should be carried by the users, not the models. An AI-native setup is thus bring-your-own-knowledge-and-hardware (BYOKH). It doesn’t mean one needs to avoid the use of frontier, centralized providers. It does mean, though, that your company is a house of cards if you’re operationally coupled to those providers.