Richard Brown = righteous bro. Just about there – except a Thelonious Chain, per my correspondence with Tim Swanson, works like this:
It’s not our protocol. It’s a developer protocol. We build the tools, they make the rules.
I think the key takeaway point… is this. It’s sort of like Nick Szabo’s blockchain computer (albeit an Apple 1 version of it). There are no mystical powers to a blockchain – it is a data structure. But you can parameterise the data structure to address pain points where you currently rely on multiple-redundant (hardware and labour) systems to achieve that verification.
Where those pain points are will differ from case-to-case and application-to-application. It’s something that you can’t know in advance – businesses need to do the analysis and come up with proposed deployments, and it’s best for them to do so, as they are far and away in the best position to know how their business is structured and where the humans and hardware need to come out (and then, how to design a system of smart contracts tailored to address it).
That’s why Thelonious is a smart contract-enabled blockchain design, a template to create blockchains, instead of a single one – because developers, not us, are in a way better position to establish what those pain points are and how to address them.
Thus they set the parameters, and we don’t. We just give them the enterprise-compatible, open-ended, smart contract-enabled, and smart contract-controlled framework over which they can drape their particular problem, define it, code it, test it, solve it, and (while still benefiting from the security of public-key cryptography) improve it later thanks to the GenDoug kernel, and without needing to fork the chain.
Our job over the next couple of years is to make sure we keep building the tools that help them achieve that as easily and safely as possible.
