A Brief History of Blockchain Interoperability
cacm.acm.org
cacm.acm.org
I don't understand what sort of people can write rubbish like this. We need human-human interactions that are transparent, dependable, resilient, and global; and therefore blockchain? What are the authors smoking?
None of this requires the specific (and pernicious) distinguishing feature of blockchain: permissionlessness (enabling the wanton abandonment of the rule of law we see in that space in practice). Good old 1990's distributed computing technology (permissioned!) allows for transparent, dependable, resilient, and global interactions (machine to machine though; I have no clue how the authors interact with other humans. Presumably with WhatsApp or iMessage, which are neither transparent nor without a single point of failure, but are just fine.)
no mention of drinking from the money-matters-most crowd .. how convenient
An allergic reaction to the term "blockchain" is to miss the forrest for the trees... and I would imagine the authors share the same point of view.
This applies only to the laws of the legacy states, not the laws of mathematics.
Blockchains are a highly lawful place in this sense.
...nor is that desirable, or a goal of decentralization. Quite the contrary.
Adding to your point that we had the decentralized "future" promised by blockchains in the 90s, "Machine Learning" is a field older than computers. Every decade it gets a new buzzword painted on (now it's "AI"), but in the end it's all just applied statistics, linear algebra, and optimization.
https://en.wikipedia.org/wiki/Cryptocurrency_in_Nigeria
Or look at Zimbabwe just two days ago. There goes 40% of your savings in that new supposedly gold-backed fiat currency...
The fact that the elite in Nigeria (those that can self-custody private keys safely, e.g. on multiple electronic devices, or a safe in their house) can now also hold unregulated USD-like funds, will that increase or decrease the pressure on the government in Nigeria to provide proper money?
I find that almost all (non-blockchain-space) tech people who find "blockchains" interesting as a concept, and see potential use-cases for them in system architecture design, are actually thinking about the uses of this taxonomic parent category — whether they realize it or not.
But the only way to currently talk about this concept — in a way that doesn't require you to first give an extensive definition of the idea you're talking about — is to use the word "blockchain", even though that's not precisely what you mean.
Since there's no software system that's just one of these things, without also being a blockchain, there's no word we've invented to talk about the set of such software systems.
If someone came along and actually made a piece of software that was all the things a blockchain is, except for the "open submission of transactions, with spam control using eStamps that necessitate the introduction of a whole economy into the system that it doesn't otherwise require" part, I think it'd become a huge thing among tech crowds, and "blockchains" as infra systems would be completely forgotten about in favor of (whatever name these parent-category systems would be given once we have any to talk about.)
Sadly, I think there's very little interest in doing this, for two reasons:
1. Anyone who builds such a system knows that with just a little bit of extra implementation effort, they can introduce such an economy, turning their thingy into a "blockchain", and potentially making a bajillion dollars by being the first one in the door of that new economy as it grows with usage.
2. Most blockchain node software is designed to be flexible-enough in its definition of a blockchain network, that it can be flexed toward being used in a "Proof-of-Authority" network implementation that doesn't actually have an internal economy. And, because blockchain node software has a lot of engineering effort already invested into it, vs. systems of this parent category that have none yet — it makes a lot of sense, as a systems engineer who just wants an infra component to slap into place, to use blockchain-node software for these use-cases, configured into a Proof-of-Authority mode where the economy logic is vestigial. It feels like an "overkill" solution, but the alternative would be DIYing a parent-category system and having to learn all the Hard Lessons that blockchain-software engineers already figured out about non-repudiability, storage architectures amenable to state garbage-collection, scalable consensus mechanisms that don't halt-and-catch-fire during hard-fork network upgrades, etc.
Would you know of any projects around this idea? As far as I'm aware, "making spam costly" has always been the big kicker that has made every decentralized-permissionless-ledger project invariably include its own coin (and associated economy) to enforce that costliness. The only idea off the top of my head would be something like "PoW, but anyone adding data just pays the miners directly via some secondary market", which would still have pathologies of its own.
If that isn't your use-case, though — if you remove or weaken at least one of those design-space constraints — then things can change.
For example, if the "ledger" in your use-case doesn't need to retain transaction history in a distributed, uncensorable, online state indefinitely; but rather can function with a history that's continuously being "offlined" past some finality threshold, converted into e.g. files in some agreed-upon format made available through BitTorrent (that have a bijective relationship with the data held in an archive node) — then you no longer need "spam control"; you only need "flood control." Compare/contrast: NNTP as a store-and-forward mechanism (needs spam control), vs IRC as a forward-and-forget mechanism (only needs flood control.) And flood control doesn't need eStamps; just much more boring infra-level solutions — node txpools that impose rate limits on messages buffered per peer and per signer per minute; validator nodes putting signers on a fail2ban-like temporary blacklist whenever a non-trivial fraction of their transactions are failing (and so wasting the validator's CPU-time); and so on.
In such a system, you might want it to be expensive to generate a new signing key. IMHO this is an actually-valid use-case for Proof-of-Work: a one-time account-onboarding-time cost that serves as an anonymous equivalent to the barriers imposed by KYC/AML, making it so that spammers have to pay that fee again when blocked, and/or pay it O(N) times to send O(N) times as much spam (but where the spam is likely able to be recognized by signature and blocked with only O(log N) effort.)
Essentially, if you aren't concerned with total spam accumulated over the lifetime of the chain, only with the rate of spam the network has to handle — then you can simply charge spammers (and transactors generally) in time, rather than in economic value.
The paper gets rather hand-wavey when discussing inter-blockchain bridges and trust. But they don't have a solution. They wrote:
"Having already implicitly addressed generalizability (the ability to process arbitrary data) and extensibility (the support of and effort required to expand an interoperability system with new chains), trustlessness undeniably represents the most important dimension, practically speaking, given the number of hacks and amount of damage already suffered by the space.g,4,10 Trustlessness—a measure for the additional trust required from users of an interoperability system beyond that in the underlying source and destination chains—is closely related to the solution’s verification mechanism, potential further trust, and liveness assumptions; and together with these, it constitutes protocol-sided security. However, given the difficulty of reliably assessing highly complex systems with unique architectures, constantly changing maturity, and under permanent threat from a variety of risks and attack vectors, a new approach to trust in interoperability is to look at it as a spectrum."
"Look at it as a spectrum" means "we don't know how to fix this."
There are lots of schemes to fix this.[1] They're really complicated (hence vulnerable), slow, or not really trustless. It's a hard problem. Throwing buzzwords at it does not help.
[1] https://medium.com/connext/the-interoperability-trilemma-657...
The code is (or should be) fully auditied and there is absolutly no chance for anyone to "steal assests while in transit", in fact, I'm hard pressed to even understand what you mean by "steal in transit"?
The authors may sound "hand-wavy" about it only because its a solved problem.
But not just one of them.
It's hard for a "smart contract" to securely do a transaction on a blockchain not its own. A trustless system needs an atomic commit across two different blockchains, which is hard.
See [1].
[1] https://www.cnbc.com/2022/08/10/hackers-have-stolen-1point4-...
- Bitcoin Drivechain Capabilities [1].
- Dogethereum: A Decentralized Blockchain Bridge Between Dogecoin and Ethereum is Born [2].
- BitVMX is a new framework to optimistically execute arbitrary programs in Bitcoin based on the N-party disputable computation paradigm pioneered by BitVM [3]
I'd like to complement this thread with a whitepaper I'm currently writing on a new L1 solution called Roughchain. I've included a preface titled "Web3 for Skeptics" to align with the perspectives of the HN community. I'll be working on the draft this Sunday, and while it’s still incomplete, I’d appreciate any thoughts or feedback. Feel free to comment [4].
[1] https://github.com/rsksmart/bips/blob/master/BIP-R11.md
[2] https://www.coinfabrik.com/blog/dogethereum-blockchain-bridg...
[4] https://docs.google.com/document/d/1FXv0Fp2R6UEs2s4_GiAw4b93...
- You don't explain that BFT in SMR is also a property of pre-blockchain 1990's permissioned systems such as PBFT or (Byzantine) Paxos. You don't distinguish between LCR + PoW (Nakamoto consensus) systems and PBFT + PoS systems that have much better latency and finality properties.
- You suggest a "governed" list of signers. If this is permissioned, then this might be a system that's "as good as it gets" in terms of low-latency, high-throughput SMR, and could be well-governed (law abiding). But then I'd eschew the blockchain moniker, as that's so tainted with fraud and BS.
- The "Introduction for crypto skeptics" does nothing to alleviate the crypto skeptics' concerns.
- You claim that updating protocols used by multiple parties is "obviously time and resource consuming" (correctly, in my view), then claim that smart contracts can somehow solve this (incorrectly, in my view) without any motivation or explanation or evidence whatsoever, except to say that "automating the process" is more efficient. Yes, obviously automating processes is more efficient than doing them manually, but how do smart contracts allow you to automate the process of updating a protocol when new circumstances arise?
I'll make sure to include a stronger technical background. Although it's a whitepaper (not a full research paper), I agree that it should be approachable from different critical perspectives.
Regarding your comments:
I see the need to distinguish more clearly between BFT in pre-blockchain systems like PBFT/Paxos and more modern PoW/PoS consensus systems. I'll refine that distinction.
I do have a specific catch in mind regarding the "governed list of signers" that I'd love your thoughts on when I include it. It might align more with the type of well-governed, high-throughput systems you're describing, but I understand your concern about using the blockchain label, which can carry negative connotations.
As for the "Introduction for crypto skeptics," I'd really appreciate hearing more from your perspective on how to make that section more convincing. What do you think would help, if possible, alleviate those concerns?
On the topic of updating protocols: I was trying to highlight the challenges of moving from specification to implementation in multiparty contexts (based on experience with government agencies), the idea is independent from blockchains.
Lastly, this is a side project for me, so progress might be gradual, but I would truly value your input again as it evolves. Would you be open to reviewing updates from time to time?
I confess that I'm not sure what these first two sentences of the article mean; here's my best guess:
> Blockchain interoperability ALLOWS distributed systems to communicate with third-party systems without a canonical chain or orchestration layer. As there is no “chain to rule them all” (for performance, privacy, and market REASONS), these distributed systems rely on exchanging data and value across network boundaries.
So, offloading is the only way to make them usable again.
I off-ramp only every second month because of absurd gas costs on Ethereum.