Bridges between separate blockchains have, at least briefly, custody of the asset. Most bridges work by transferring the asset to the bridge, with instructions to transfer it onward to some other wallet. Which is why bridges can steal the asset while in transit. This happens. A lot, to the tune of about US$3 billion so far.
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...
Isn't the basic idea that one blockchain runs the code to be able to (1) "Look up" a trade price, (2) Okay it with both users, (3) Then simply make the two transactions?
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.
> The current socio-economic environment, including rapid digitization of information and processes, the rise of machine learning (ML), and ubiquitous access to the Internet, amplifies the need for human-human and human-machine interactions that are transparent, dependable, resilient, and operate at a global scale—without a single point of failure. This might ring a bell; the concept of distributed ledger technologies (DLT), or blockchain, refers to systems implementing these properties.
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.)
People [sadly] put a lot of "exotic" cryptography/distributed systems under the term "blockchain" eg. If you want to do byzantine agreement with sub quadratic message complexity, where do you look it up? If you want to do high throughput threshold signing, where do you look it up?
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.
> the rise of machine learning (ML)
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.
> the wanton abandonment of the rule of law we see in that space in practice
This applies only to the laws of the legacy states, not the laws of mathematics.
Blockchains are a highly lawful place in this sense.
Only insofar as those in power (whether it's soft or hard power) agree to be bound by the mathematical laws. See: the forking of Ethereum from Ethereum Classic, even if the people in charge of the project pinky-promise not to do that again. The underlying social forces can't be eliminated from the equation, as long as humans are involved.
I didn't really infer that meaning. It sounds more like an innocent transition sentence and not necessarily the _only_ universal solution to that problem.
> What are the authors smoking?
no mention of drinking from the money-matters-most crowd .. how convenient
> Blockchain interoperability conflates the need for 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 forces), these distributed systems rely on exchanging data and value across network boundaries.
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.
Unfortunately, the article doesn't seem to mention the specific history of blockchain interoperability. Since I was directly or indirectly involved in these developments, I’ll start by highlighting three examples:
- 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...
Some ad-hoc feedback on [4]:
- 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?
Thank you very much for your feedback! This is a work-in-progress draft, and while I'm not exactly where I want to be yet, your insights are really helpful. Here's my first takeaway:
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?
Interoperability is essential for some of the smart contracts, but it ends up undermining much of the "wealth" that's emerged because of limits. Bitcoin, Ethereum and many of the others depend upon scarcity for their value. If one can get all of the value from blockchain by using a level two or three side chain at a much lower price, well, that's going to start undermining the central chains. And if the central chains lose support and interest, well, their price will drop. That will drive away the greedy people (which may be good).