4 ms·

If it's exclusive to machine agents there are plenty of consensus-oriented protocols already in existence that could accomplish the same goal without relying on

If it's exclusive to machine agents there are plenty of consensus-oriented protocols already in existence that could accomplish the same goal without relying on a blockchain. Machine agents are already bound by the code that executes and models them, all you'd be doing is adding a layer of consensus-driven redundancy for security reasons (both technical and social).

derefr 8y ago
> there are plenty of consensus-oriented protocols already in existence that could accomplish the same goal without relying on a blockchain Assume: 1. a distributed system where the consensus algorithm is state-dependent (in the sense that an SQL RDBMS that exposes the ability to insert rules/triggers has state-dependent consensus—different MVCC states will see different transactions as valid/invalid); 2. malicious machine-agents (bot oracles) supplying arbitrary input into the distributed system; 3. the distributed system being open-membership, such that malicious people are running auditing nodes (and so you can't really do Raft consensus); 4. the distributed system being large enough that you can't really do Paxos consensus in any efficient way. Is there any other solution to this problem, than to use the consensus algorithm of: 1. have many nodes redundantly, eagerly audit a block of new inputs; 2. on each step, choose of those blocks essentially by lottery (specifically, a lottery no individual node on the distributed system can predict or cheaply craft an input to win); 3. allow anyone who wants to, to configure their node to fully verify past blocks, such that enough nodes doing this will create "herd immunity", diverging the system away from maliciously-crafted blocks. Step 2 of the algorithm requires Proof-of-Work (so far as we know); step 3 of the algorithm requires an accessible chain of signed proofs to audit. Together, those spell "blockchain."
- TeMPOraL 8y ago
  Real-world applications rarely require all the assumptions that are necessary for blockchain to be the best solution. For instance, some real-world systems will not be distributed; others will be running under common ownership or under ownership of people who trust each other mutually, etc. There's this adage[0], that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". It's usually meant negatively, but in this case one can draw a positive conclusion - just like organizations don't need the blockchain to efficiently do their businesses, automated systems designed by those organizations may not need the blockchain either. -- [0] - https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
  - derefr 8y ago
    Sure, I don't disagree that many "blockchains" have no need to be such. There is, in my mind, justification for there existing at least one distributed computation substrate where machine-agents can basically play a https://en.wikipedia.org/wiki/Nomic https://en.wikipedia.org/wiki/Nomic together, each asserting rules into the system, and then moving data (including data representing physical assets, and new rules) around according to the thusfar-established ruleset. Basically, an extensible distributed stock market where different negotiable synthesized instruments, each with their own rules, can be brought into being and traded, without needing to get buy-in from anybody, by just throwing them on there and seeing if anybody is interested. (You know, the thing that there was enough pent-up demand for that the very first even-somewhat-viable distributed computation substrate, Ethereum, was forced into this shape despite not being very well-suited for the job, having been designed for entirely different kinds of computation.) That's pretty much the only good case for a smart-contract blockchain as such that I know of, though.
    - jonnydubowsky 8y ago
      Thanks for introducing me to Nomic games. I think it would benefit those interested in improving on current smart contract implementations to put away the computer for a few days, and just map out the value stream and logical(and often illogical) behavior of the humans, including whatever steps can be taken to supercede the code, in the physical world. I wonder if Nick Szabo had any interactions in this space before coming up with the first ideas for implementing smart contracts. For those interested in the history of smart contracts, check out https://en.m.wikipedia.org/wiki/Smart https://en.m.wikipedia.org/wiki/Smart Contract .Szabo proposes that smart contract infrastructure can be implemented by replicated asset registries and contract execution using cryptographic hash chains and Byzantine fault tolerant replication. Askemos implemented this approach in 2002 using Scheme later adding SQLite as contract script language. The precursor to smart contracts was Ian Griggs idea on Ricardian Contracts https://en.m.wikipedia.org/wiki/Ricardian_contract https://en.m.wikipedia.org/wiki/Ricardian_contract

derefr 8y ago

> there are plenty of consensus-oriented protocols already in existence that could accomplish the same goal without relying on a blockchain Assume: 1. a distributed system where the consensus algorithm is state-dependent (in the sense that an SQL RDBMS that exposes the ability to insert rules/triggers has state-dependent consensus—different MVCC states will see different transactions as valid/invalid); 2. malicious machine-agents (bot oracles) supplying arbitrary input into the distributed system; 3. the distributed system being open-membership, such that malicious people are running auditing nodes (and so you can't really do Raft consensus); 4. the distributed system being large enough that you can't really do Paxos consensus in any efficient way. Is there any other solution to this problem, than to use the consensus algorithm of: 1. have many nodes redundantly, eagerly audit a block of new inputs; 2. on each step, choose of those blocks essentially by lottery (specifically, a lottery no individual node on the distributed system can predict or cheaply craft an input to win); 3. allow anyone who wants to, to configure their node to fully verify past blocks, such that enough nodes doing this will create "herd immunity", diverging the system away from maliciously-crafted blocks. Step 2 of the algorithm requires Proof-of-Work (so far as we know); step 3 of the algorithm requires an accessible chain of signed proofs to audit. Together, those spell "blockchain."

TeMPOraL 8y ago
Real-world applications rarely require all the assumptions that are necessary for blockchain to be the best solution. For instance, some real-world systems will not be distributed; others will be running under common ownership or under ownership of people who trust each other mutually, etc. There's this adage[0], that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". It's usually meant negatively, but in this case one can draw a positive conclusion - just like organizations don't need the blockchain to efficiently do their businesses, automated systems designed by those organizations may not need the blockchain either. -- [0] - https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- derefr 8y ago
  Sure, I don't disagree that many "blockchains" have no need to be such. There is, in my mind, justification for there existing at least one distributed computation substrate where machine-agents can basically play a https://en.wikipedia.org/wiki/Nomic https://en.wikipedia.org/wiki/Nomic together, each asserting rules into the system, and then moving data (including data representing physical assets, and new rules) around according to the thusfar-established ruleset. Basically, an extensible distributed stock market where different negotiable synthesized instruments, each with their own rules, can be brought into being and traded, without needing to get buy-in from anybody, by just throwing them on there and seeing if anybody is interested. (You know, the thing that there was enough pent-up demand for that the very first even-somewhat-viable distributed computation substrate, Ethereum, was forced into this shape despite not being very well-suited for the job, having been designed for entirely different kinds of computation.) That's pretty much the only good case for a smart-contract blockchain as such that I know of, though.
  - jonnydubowsky 8y ago
    Thanks for introducing me to Nomic games. I think it would benefit those interested in improving on current smart contract implementations to put away the computer for a few days, and just map out the value stream and logical(and often illogical) behavior of the humans, including whatever steps can be taken to supercede the code, in the physical world. I wonder if Nick Szabo had any interactions in this space before coming up with the first ideas for implementing smart contracts. For those interested in the history of smart contracts, check out https://en.m.wikipedia.org/wiki/Smart https://en.m.wikipedia.org/wiki/Smart Contract .Szabo proposes that smart contract infrastructure can be implemented by replicated asset registries and contract execution using cryptographic hash chains and Byzantine fault tolerant replication. Askemos implemented this approach in 2002 using Scheme later adding SQLite as contract script language. The precursor to smart contracts was Ian Griggs idea on Ricardian Contracts https://en.m.wikipedia.org/wiki/Ricardian_contract https://en.m.wikipedia.org/wiki/Ricardian_contract