10 ms·

I can't say I'm all that surprised. R3 serves as both an R&D lab and a place to connect vendors and potential clients. Moreover, the focus is on private/permiss

by buckie 10y ago

I can't say I'm all that surprised. R3 serves as both an R&D lab and a place to connect vendors and potential clients. Moreover, the focus is on private/permissioned blockchain tech. The tech in this space is still quite immature overall and pretty much everyone has had a hard time building actual blockchain infrastructure vs things that are sorta like a blockchain. If you can't show clients value for their membership in R3 (because the tech's not there) then what's the value of staying a member (especially if you've seen all the vendors in their portfolio already) vs rejoining when things change? This isn't R3's fault of course, as I think the tech in this space is just getting started and they're in a great place to help it along; members will come and go. I spent a year investigating blockchain applications for JPM so I've seen most of the permissioned blockchain solutions that are out there. Unfortunately, none of the solutions I saw were real blockchains. The more technical groups in banks (which GS has) surely realize this as well. The solutions I've seen consistently lack at least one of the following necessary features: - Fast, Deterministic BFT Consensus (mining doesn't work as intended in private contexts[1]) - Smart Contracts (you need a deterministic language) - Signed Transactions (TLS based authentication trades security & audibility for speed) - Cryptographic data structure for transaction storage There are other features you need, but these are the big distinguishers I noticed. While technically you don't even need smart contracts or fast BFT consensus, I believe the tech isn't useful enough to justify the migration costs without them. Disclaimer: I'm a founder in the private blockchain space[2] and founded specifically to make an infrastructure that addresses these issues. [1]: http://kadena.io/blog/MiningInPrivate.html http://kadena.io/blog/MiningInPrivate.html [2]: http://kadena.io http://kadena.io

jaekwon 10y ago
Kadena seems like a solid team, kudos for their work. Smart contracts require you to work in a completely new language and toolset. You don't need smart contracts to create a blockchain application, if you use the right libraries (e.g. go-merkle) and write your application to be deterministic. See Basecoin in the page below: http://tendermint.com/ecosystem http://tendermint.com/ecosystem If you want the benefits of Tendermint BFT consensus but w/ Ethereum's virtual machine, take a look at Ethermint. http://github.com/tendermint/ethermint http://github.com/tendermint/ethermint Disclaimer: I'm a founder at Tendermint, the OG BFT blockchain engine. ;)
- buckie 10y ago
  Smart contracts definitely have a tradeoff between new toolset/languages vs infrastructure level features. With smart contracts, anyone can write code for the chain vs the "write your application to be deterministic" approach where new code needs to be at a minimum vetted by some central org/group, though they're usually written by the vendor/provider/etc. Each has its strengths/use-cases. For inter-org I prefer the smart contract approach vs the intra-org can see the benefit of using regular code -- it's not like you're worried about malicious code in the intra-org case. I do think that smart contracts increase the utility overall (sorta like having SQL for a DB > not) and improve its reliability (accidentally non-deterministic code can be a bit worrying). As for Tendermint BFT, it's one of the few that somehow I never got to dig into at JPM. Do you know if Tendermint BFT's performance & performance-vs-scale numbers are published? These are notoriously hard to come by and I'm always curious for more data-points on the matter.
- murbard2 10y ago
  If you want a deterministic smart contract language, you're better off avoiding the EVM, or worse, Solidity. Tezos (plug, plug, I'm the lead on the project) has a VM with a full formal specification, and even a rudimentary embedding in Coq. It's statically typed and purely functional. https://tezos.com/language.txt https://tezos.com/language.txt
  - jaekwon 10y ago
    We should plug Tendermint into Tezos as well.
    - murbard2 10y ago
      My thinking for v2 is to use Honey Badger BFT, with multi party computation for bonding / unbonding Overall I agree with Tendermint (and contra Casper or DFinity) that it's better to just drop availability and to have a less subjective security model. It sucks to get stuck if the validator set becomes compromised, but it's not the end of the world.
wyldfire 10y ago
Why doesn't the financial industry consider a public blockchain? How do big financial companies consider resolving adversity like judgments/liens/etc against an settlement based system that's an automaton?
- known 10y ago
  Accounting, auditing and compliance are a massive cost for business globally. (Fines alone have cost banking $200 billion since 2009.) Blockchain accounting could help cut those costs. For example, instead of a company employing its own auditors to examine the books of its various units, all transactions could be logged on an internal blockchain, and recorded centrally. Likewise, external auditors or even regulators could inspect a corporation’s books in real time. Even the accounting firms that make their money from auditing see the value in the technology: “This solution could significantly reduce the reliance on auditors for testing financial transactions,” Matt Spoke http://qz.com/629662/the-unsexy-future-of-blockchain-is-accounting/ http://qz.com/629662/the-unsexy-future-of-blockchain-is-acco...
  - sseveran 10y ago
    Banks typically already have some sort of realtime risk management system. Goldman's SecDB is quite famous. Banks typically have whatever risk controls in place they want. Blockchains aren't going to provide any magic here. The fines banks have faced haven't come from the lack of a central repository of trades.
- deleted 10y ago
  [deleted]
- appleflaxen 10y ago
  the real answer is because they have a monopoly on clearance mechanisms in the status quo, and want to retain control over it.
  - nickonline 10y ago
    Almost none of the use cases financial institutions look to blockchain to solve have anything to do with settlement or clearance.
generalseven 10y ago
If it's going to be a permissioned system anyway, wouldn't you get better performance from a non-blockchain solution? The permissioned blockchains are being called "a horseless carriage with a horse" by Andreas Antonopoulos.
- kpil 10y ago
  True. I think that there is no way to compete against the speed and relative non-complexity you can get from "closed group, trusted 3rd party" solutions. There is so much hype and confusion spread around the issue - as there are some genuine threats to some of the bread-and-butter services the banks do, like accounts and payments. But to put it mildly, the bank executives are for the most time not really in the right career to sort out what's what, and due to the way the banks work, they are not likely to listen to the people that actually know how to do that until a lot of money is wasted and very little has been gained.
- buckie 10y ago
  Maybe, our system gets 8k-12k transactions per second with full replication + crypto up to a few thousand consensus nodes (slows down around 4k nodes). That type of performance opens up a lot of potential applications. As for "a horseless carriage with a horse" perhaps, we'll see. These systems do give you something that you can't get otherwise which is a distributed DB that you can share with competitors without worrying about them stealing from you/breaking it. Blockchain is to overloaded right now, but it's the name that has stuck likely because "a Byzantine-Fault-Tolerant Consensus database" (BFTCDB) is just too impenetrable. If one of these BFTCDB take off, if may not actually be a blockchain (though I suspect it will be because cryptographic data structures are just too useful for them) but I bet it will be called one. But that the end of the day, that's what a permissioned blockchain is -- a DB you can share, which is a seriously new capability.
cm2187 10y ago
I would be curious to understand what problems these blockchains solve. Intuitively, they do not seem like obvious candidates for financial transactions. 1. They really shine in a p2p architecture where no party trusts each other. But that's not how the financial system works. Banks trust central banks, exchanges and clearing houses, and it is very much a club where players have to be vetted and monitored by a regulator, quite far from the open and wild nature of p2p systems. 2. Market participants need anonymity. Morgan Stanley might not know who hides behind the cryptographic key xxxxx until they do a trade with Goldman Sachs, see that trade appearing in the public ledger and then suddenly they see every single transaction Goldman has done since the dawn of times. Markets need anonymity otherwise market participants can arbitrage you based on what they know you need or plan to do. And the transparency of the public ledger is a fundamental problem. 3. Regulators need transparency. The regulators will need a centralised place where they can put a name against every transaction. That I would thought almost defeats the purpose of the ledger since a traditional transaction log will have to be maintained on the side. Now you have two ledgers. I remember this excellent blog article explaining when blockchains are pointless and unless I missed something, financial transactions do not meet conditions 3 (Absence of Trust), 4 (Disintermediation). http://www.multichain.com/blog/2015/11/avoiding-pointless-blockchain-project/ http://www.multichain.com/blog/2015/11/avoiding-pointless-bl...
- davidgerard 10y ago
  > I would be curious to understand what problems these blockchains solve. Buzzword compliance. I predict you will see "Blockchain" products that contain transactions in a Merkle tree as the only technological link to actual blockchains. (R3 have one already, R3 Corda.)
- buckie 10y ago
  I'd say there are a few ways to think about blockchain's utility in private contexts (public chains are pretty different because of their ability to allow for anonymous participation). The two best ones are the intra- and inter-organization use cases. For intra-organization, one way to view private blockchains is to look back to the days of mainframes and the shift to databases. While you technically never need a DB and can get things done with code, DB's are incredibly useful as a general utility because of the baseline features you get by using one. Private blockchains are similar, in that they give you some new features (e.g. sharable DBs) and are much easier to build with as they raise the baseline on how bad a solution can be that is built with them. While you can have a pretty messed up DB schema, bespoke mainframe solutions can be much worse. Private blockchains are like that (especially when they have smart contracts) -- sure you can really mess up the systems setup but issues that DB's can have like high availability and disaster recovery are 100% commoditized. Also, they demand a higher bar for authorization making them generally as more robust the most hardened DB by default. That isn't to say that a private blockchain will replace the DB as blockchains can be wild overkill for many domains. A small company that needs a DB doesn't need a blockchain's feature set, but a large company that needs a globally distributed DB for holding a ledger (of anything) would be well served by one. When you're working with a system that by default is BFT, incredibly paranoid about authorization, perfectly replicated and highly available then build a solution gets much easier. As for the specific problem that they solve, it's the settlement problem: organizations currently hold internal ledgers of truth about what they own but they can't inherently trust other organizations' ledgers of truth about what they own, so we need 3rd parties to settle cross-ledger. Currently, institutions handle this role but private blockchains represent an algorithmic solution.
m3ta 10y ago
> - Signed Transactions (TLS based authentication trades security & audibility for speed) I think you meant "auditability". How are "Signed Transactions" an upgrade from TLS 1.2? How is TLS trading security for speed?
- buckie 10y ago
  I did, though I can't edit it now sadly. And it's not that TLS isn't secure but about what features TLS gives the system. The gist of this is that TLS doesn't give one a durable/persistable form of security vs ppk-sig's ability to verify that x signed y at any time. TLS is much faster than verifying the sig with every transaction on every node but after, say, a cluster restart the question of "who sent x" is answered via consensus and not cryptography. There are a couple other issues too. Using ppk-sigs means that the mail clerk and the CEO use different keys to sign transactions vs TLS where you'd either have a logical "from:" field or a different connection for different users. Both of the TLS solutions have rather obvious flaws. Finally, a TLS based approach puts an attacker 1 server away from impersonating, potentially, an entire organization because the system using TLS cares only that it came via the correct pipe. Overall I'd describe systems using TLS as not being paranoid enough about who authored a transaction, as PBFT/SmartBFT are by default very trusting of a client's transactions vs Bitcoin's model where everything is to be questioned/require independently verifiable cryptographic proof. Hence the tradeoff.

by buckie 10y ago

jaekwon 10y ago

Kadena seems like a solid team, kudos for their work. Smart contracts require you to work in a completely new language and toolset. You don't need smart contracts to create a blockchain application, if you use the right libraries (e.g. go-merkle) and write your application to be deterministic. See Basecoin in the page below: http://tendermint.com/ecosystem http://tendermint.com/ecosystem If you want the benefits of Tendermint BFT consensus but w/ Ethereum's virtual machine, take a look at Ethermint. http://github.com/tendermint/ethermint http://github.com/tendermint/ethermint Disclaimer: I'm a founder at Tendermint, the OG BFT blockchain engine. ;)

buckie 10y ago
Smart contracts definitely have a tradeoff between new toolset/languages vs infrastructure level features. With smart contracts, anyone can write code for the chain vs the "write your application to be deterministic" approach where new code needs to be at a minimum vetted by some central org/group, though they're usually written by the vendor/provider/etc. Each has its strengths/use-cases. For inter-org I prefer the smart contract approach vs the intra-org can see the benefit of using regular code -- it's not like you're worried about malicious code in the intra-org case. I do think that smart contracts increase the utility overall (sorta like having SQL for a DB > not) and improve its reliability (accidentally non-deterministic code can be a bit worrying). As for Tendermint BFT, it's one of the few that somehow I never got to dig into at JPM. Do you know if Tendermint BFT's performance & performance-vs-scale numbers are published? These are notoriously hard to come by and I'm always curious for more data-points on the matter.
murbard2 10y ago
If you want a deterministic smart contract language, you're better off avoiding the EVM, or worse, Solidity. Tezos (plug, plug, I'm the lead on the project) has a VM with a full formal specification, and even a rudimentary embedding in Coq. It's statically typed and purely functional. https://tezos.com/language.txt https://tezos.com/language.txt
- jaekwon 10y ago
  We should plug Tendermint into Tezos as well.
  - murbard2 10y ago
    My thinking for v2 is to use Honey Badger BFT, with multi party computation for bonding / unbonding Overall I agree with Tendermint (and contra Casper or DFinity) that it's better to just drop availability and to have a less subjective security model. It sucks to get stuck if the validator set becomes compromised, but it's not the end of the world.

wyldfire 10y ago

Why doesn't the financial industry consider a public blockchain? How do big financial companies consider resolving adversity like judgments/liens/etc against an settlement based system that's an automaton?

known 10y ago
Accounting, auditing and compliance are a massive cost for business globally. (Fines alone have cost banking $200 billion since 2009.) Blockchain accounting could help cut those costs. For example, instead of a company employing its own auditors to examine the books of its various units, all transactions could be logged on an internal blockchain, and recorded centrally. Likewise, external auditors or even regulators could inspect a corporation’s books in real time. Even the accounting firms that make their money from auditing see the value in the technology: “This solution could significantly reduce the reliance on auditors for testing financial transactions,” Matt Spoke http://qz.com/629662/the-unsexy-future-of-blockchain-is-accounting/ http://qz.com/629662/the-unsexy-future-of-blockchain-is-acco...
- sseveran 10y ago
  Banks typically already have some sort of realtime risk management system. Goldman's SecDB is quite famous. Banks typically have whatever risk controls in place they want. Blockchains aren't going to provide any magic here. The fines banks have faced haven't come from the lack of a central repository of trades.
deleted 10y ago
[deleted]
appleflaxen 10y ago
the real answer is because they have a monopoly on clearance mechanisms in the status quo, and want to retain control over it.
- nickonline 10y ago
  Almost none of the use cases financial institutions look to blockchain to solve have anything to do with settlement or clearance.

generalseven 10y ago

If it's going to be a permissioned system anyway, wouldn't you get better performance from a non-blockchain solution? The permissioned blockchains are being called "a horseless carriage with a horse" by Andreas Antonopoulos.

kpil 10y ago
True. I think that there is no way to compete against the speed and relative non-complexity you can get from "closed group, trusted 3rd party" solutions. There is so much hype and confusion spread around the issue - as there are some genuine threats to some of the bread-and-butter services the banks do, like accounts and payments. But to put it mildly, the bank executives are for the most time not really in the right career to sort out what's what, and due to the way the banks work, they are not likely to listen to the people that actually know how to do that until a lot of money is wasted and very little has been gained.
buckie 10y ago
Maybe, our system gets 8k-12k transactions per second with full replication + crypto up to a few thousand consensus nodes (slows down around 4k nodes). That type of performance opens up a lot of potential applications. As for "a horseless carriage with a horse" perhaps, we'll see. These systems do give you something that you can't get otherwise which is a distributed DB that you can share with competitors without worrying about them stealing from you/breaking it. Blockchain is to overloaded right now, but it's the name that has stuck likely because "a Byzantine-Fault-Tolerant Consensus database" (BFTCDB) is just too impenetrable. If one of these BFTCDB take off, if may not actually be a blockchain (though I suspect it will be because cryptographic data structures are just too useful for them) but I bet it will be called one. But that the end of the day, that's what a permissioned blockchain is -- a DB you can share, which is a seriously new capability.

cm2187 10y ago

I would be curious to understand what problems these blockchains solve. Intuitively, they do not seem like obvious candidates for financial transactions. 1. They really shine in a p2p architecture where no party trusts each other. But that's not how the financial system works. Banks trust central banks, exchanges and clearing houses, and it is very much a club where players have to be vetted and monitored by a regulator, quite far from the open and wild nature of p2p systems. 2. Market participants need anonymity. Morgan Stanley might not know who hides behind the cryptographic key xxxxx until they do a trade with Goldman Sachs, see that trade appearing in the public ledger and then suddenly they see every single transaction Goldman has done since the dawn of times. Markets need anonymity otherwise market participants can arbitrage you based on what they know you need or plan to do. And the transparency of the public ledger is a fundamental problem. 3. Regulators need transparency. The regulators will need a centralised place where they can put a name against every transaction. That I would thought almost defeats the purpose of the ledger since a traditional transaction log will have to be maintained on the side. Now you have two ledgers. I remember this excellent blog article explaining when blockchains are pointless and unless I missed something, financial transactions do not meet conditions 3 (Absence of Trust), 4 (Disintermediation). http://www.multichain.com/blog/2015/11/avoiding-pointless-blockchain-project/ http://www.multichain.com/blog/2015/11/avoiding-pointless-bl...

davidgerard 10y ago
> I would be curious to understand what problems these blockchains solve. Buzzword compliance. I predict you will see "Blockchain" products that contain transactions in a Merkle tree as the only technological link to actual blockchains. (R3 have one already, R3 Corda.)
buckie 10y ago
I'd say there are a few ways to think about blockchain's utility in private contexts (public chains are pretty different because of their ability to allow for anonymous participation). The two best ones are the intra- and inter-organization use cases. For intra-organization, one way to view private blockchains is to look back to the days of mainframes and the shift to databases. While you technically never need a DB and can get things done with code, DB's are incredibly useful as a general utility because of the baseline features you get by using one. Private blockchains are similar, in that they give you some new features (e.g. sharable DBs) and are much easier to build with as they raise the baseline on how bad a solution can be that is built with them. While you can have a pretty messed up DB schema, bespoke mainframe solutions can be much worse. Private blockchains are like that (especially when they have smart contracts) -- sure you can really mess up the systems setup but issues that DB's can have like high availability and disaster recovery are 100% commoditized. Also, they demand a higher bar for authorization making them generally as more robust the most hardened DB by default. That isn't to say that a private blockchain will replace the DB as blockchains can be wild overkill for many domains. A small company that needs a DB doesn't need a blockchain's feature set, but a large company that needs a globally distributed DB for holding a ledger (of anything) would be well served by one. When you're working with a system that by default is BFT, incredibly paranoid about authorization, perfectly replicated and highly available then build a solution gets much easier. As for the specific problem that they solve, it's the settlement problem: organizations currently hold internal ledgers of truth about what they own but they can't inherently trust other organizations' ledgers of truth about what they own, so we need 3rd parties to settle cross-ledger. Currently, institutions handle this role but private blockchains represent an algorithmic solution.

m3ta 10y ago

> - Signed Transactions (TLS based authentication trades security & audibility for speed) I think you meant "auditability". How are "Signed Transactions" an upgrade from TLS 1.2? How is TLS trading security for speed?

buckie 10y ago
I did, though I can't edit it now sadly. And it's not that TLS isn't secure but about what features TLS gives the system. The gist of this is that TLS doesn't give one a durable/persistable form of security vs ppk-sig's ability to verify that x signed y at any time. TLS is much faster than verifying the sig with every transaction on every node but after, say, a cluster restart the question of "who sent x" is answered via consensus and not cryptography. There are a couple other issues too. Using ppk-sigs means that the mail clerk and the CEO use different keys to sign transactions vs TLS where you'd either have a logical "from:" field or a different connection for different users. Both of the TLS solutions have rather obvious flaws. Finally, a TLS based approach puts an attacker 1 server away from impersonating, potentially, an entire organization because the system using TLS cares only that it came via the correct pipe. Overall I'd describe systems using TLS as not being paranoid enough about who authored a transaction, as PBFT/SmartBFT are by default very trusting of a client's transactions vs Bitcoin's model where everything is to be questioned/require independently verifiable cryptographic proof. Hence the tradeoff.