/biz/ - Business & Finance

Microsoft is trying to pigeonhole some form of permission blockchain offering based on ethereum, so this makes it rather marketable to enterprise clients. They add all sorts of neat bells and whistles, but it's mostly generic offering. The latest proof of authority is raw parity with a bit of azure functionality added.
BigchainDB looks nice, but not really a replacement for a enormously large databases despite the name. No smart contract capability either. Nodes relying on proper database servers, which makes it quite scalable for a blockchain. Tendermint based.
Hyperledger Fabric looks rather nice and is being pushed into the space as a premier option. Is it really that good? Ethereum is battle tested already, seems more marketable to base any offerings on eth based stuff.
JP Morgans Quorum seems superb. The BFT consensus algorithm seems like a recent addition which makes it a bit off.
Raw Tendermint seems incredibly flexible if such flexibility is needed.
Hyperledger Burrow is a tendermint adhering eth implementation last I've checked. Seems nice.

Quite a bit of options.

>>11371118
Permissioned databases have been around forever.

One ancient example is https://github.com/benlaurie/Open-Transactions

Sadly, it never caught VC pump funding as it is inherently double-entry credit protocol (albeit much more sound one than FIX).

Crypto capital is interested only in things where you can extract rent (ethereum, ripple). Having 60%+ permanent tax hike there is not something banks are thrilled about. So they resort to obtusely reinventing the wheel on their own (hyperledger and such). They unfortunately lack any sensible drive of mature crypto markets.

>>11371798
Isn’t the primary concern for enterprise purposes that they need to follow strict regulatory requirements, and permissionless platforms like Ethereum don’t fulfill those requirements, hence the need for a permissionless alternative?

>>11371854
>permissioned

Seems like permissioned blockchains are just a bridge for governance/trust purposes until the public ones are ready and trusted

>>11371798
Open-Transactions is interesting, thanks for mentioning this.

>Crypto capital is interested only in things where you can extract rent (ethereum, ripple)

Not really interested in crypto capital. Interested in regular large enterprises/groups of those who have departments staffed full of people who reconcile records across separate databases. How would one argument for something like hyperledger fabric in front of a client?

>transaction validation is a first class citizen in this solution.
>mass redundancy, immutability and no single entity in control makes the solution perfectly resilient

Doesn't sound groundbreaking

>>11371118
so what is gonna be? will fucking kikes pump our bags or will they manage to get all the benefits of a blockchain without giving back the goyim?

That's why I'm in the 'bitcoin yes, blockchain no' Camp and proud

>>11371118
>3. Preliminary checking of transaction correctness done at initiating it, not 3 months after. Checking performed by all participants of the network in a manner resistant to malicious actors - to some degree.

I THINK this is the key but still trying to figure out whether they are going to go for it. I sort of think of it as a blockchain version of arbitration by your peers in the market. For hundreds (thousands) of years if two, whatever, cotton traders had a dispute, then they wanted it arbitrated by other cotton traders.

I THINK something analogous might happen here -- although not talking about arbitration after the fact, but the point being that, if you are dealing with, say, a big shipment, then OTHER pre-approved members of the permissioned blockchain will verify it. Kind of like a trade association.

Now, one, issue is that these transactions involve CONFIDENTIAL data that the transacting parties would not want anyone else to know. I THINK it's possible with some version of zero knowledge proofs/off chain calculations, to have other VERIFY a transaction without revealing confidential details. Sergey just talked yesterday about using chainlink for this. Also Oasis labs is working on this as well.

>>11371854
Seems so.
Permissioned blockchains can work much quicker as well now, which makes the solutions buildable potentially much more featurefull.

Also, privacy requirements for certain data. Where one entity would like to disclose this piece of information to this selected amount of parties. Th way Quorum does this is nice.

>>11371928
>Not really interested in crypto capital. Interested in regular large enterprises/groups of those who have departments staffed full of people who reconcile records across separate databases. How would one argument for something like hyperledger fabric in front of a client?

I'm most familiar with the argument wrt clearing and settlement of securities trades. Estimates are that parties will have HUGE savings by eliminating all the overhead in reconciling everyone's records. Also note that they apparently lose a LOT of money from ERRORS and scrambling to correct them.

>>11371412
>Ethereum is battle tested already, seems more marketable to base any offerings on eth based stuff.
I can't tell if that is how it is perceived by big players. My SENSE is that they view the scaling problems with ethereum blockchain as very serious -- iow "how can we trust a network that was almost brought down by people selling cartoon cats"

>>11372003
That's true. What would be the difference between this, and having a regular open API with fine grained permissions between actors? The difference might be in the way Blockchains have validation put as the main feature, so the focus shifts because it can't be pushed back.

A perfectly permissioned set of connected databases is an alternative, but not something that seems possible to implement in any realistic capacity. It comes built in in a blockchain type solution, I think

>>11372025
Scaling problems are directly related to gas limits per transaction and gas cost of doing anything on chain. This becomes moot in anything like a Proof of Authority solution, or anything similar. A potential client might be pleasantly surprised after hearing that he can use ethereum without the drawbacks of it. This is how JP Morgan tried to sell Quorum, as far as I understood.

Still, can't store a lot of data onchain - this facet of the scalability problem remains.

>>11371970
Valuable thoughts there, thank you

>>11372133
>A perfectly permissioned set of connected databases is an alternative, but not something that seems possible to implement in any realistic capacity. It comes built in in a blockchain type solution, I think

I'm still trying to wrap my head around this myself but this is my understanding. If you have a bunch of connected databases, then you, I think INEVITABLY run into the reconciliation problem and breakdown of trust. Note that, for financial transactions the VOLUME (something like 1,000,000 transactions per day in US stock market) is so IMMENSE that even if a series error is one in a million that is still one serious error per day. So the idea is that with a distributed ledger, well, you know the rest -- there is ONE ledger, and everyone has a copy. Transactions are verified by members of the permissioned blockchain, and we -- in theory -- dispense with the reconciliation process. The DLT IS the reconciled record and everyone has a copy.

>>11372186
>Scaling problems are directly related to gas limits per transaction and gas cost of doing anything on chain. This becomes moot in anything like a Proof of Authority solution, or anything similar.
Thanks for this explanation. I confess I still have only a super basic understanding of how the ethereum blockchain works. Re: the storage of data on chain/off chain, that's why I was excited to see Sergey Nazarov mention this this week. Also, apparently Oasis Labs and their ekiden is trying to address this as well. https://cryptobriefing.com/oasis-labs-ico-review-ekiden-protocol/

>>11372248
>The DLT IS the reconciled record
This sentence emits power. Something that's usable in a sale scenario. Thank you.

>>11372326
Happy to help. You obviously have experience in the enterprise space so curious what your impression is of how they view use of blockchain. I ask because I'm trying to understand challenges to adoption of smart contracts. One news story says that 80% of fortune 500 will use blockchain in two years, then other says its all hype. To the extent you can talk about it, I'm curious what you are hearing.

>>11372526
In the circles I'm in working in, permissioned blockchains are usually discarded for ideological reasons. 'not a real blockchain'. 'that's not the point of a blockchain to be permissioned'. A quick talk about potential benefits makes them scuffle back to their shell, unprepared for a conversation.
In the client, non-developer side of things, there are both executives with too much money that they know what to do with, ready for experimenting with new things. Pervasive lack of efficiency in regular day-to-day tasks in companies do to people having problems with communication due to severe trust issues. Power-hugging IT administrators making things hard for everyone. The quickest gain from Permissioned blockchain adoption would be a software-layer WORM (write-once-read-many) data store that's resistant to power-hungry IT people, incompetence of individual actors and database failures. The reconciliation patterns you've mentioned would also be implemented, but this would be very company context dependant.
Hope that helped in any capacity.

>>11372743
thanks very much. That's very helpful info. Interesting point (which I should have realized) that the trust issues are as much about the INTERNAL constituencies at a company as they are BETWEEN companies.

>>11372743
So what's your current view in permissioned vs public chains?

>>11372743
would appreciate the chance to discuss this with you offline but no hard feelings if you are not up for it. I am an attorney and entrepreneur focused on smart contracts, and particularly interested in obstacles to adoption. Trying to learn as much as I can about the space and in particular how it is perceived at enterprise level.

You can reach me at my throwaway account ms5970025@gmail.com if interested in talking further. In any case, thanks for a helpful and informative thread.