Watching the demo video [1] has me a little confused.
He makes it sound like all your interaction with Ethereum goes through the Coco framework (so permissions are implemented by Coco deciding which contracts you're allowed to see). Is that right?
If so what's the point of using Ethereum at all?
- Who is doing the computation for a smart contract if it's private and only you can see it?
- Is the permissioning managed by a trusted Coco server somewhere? If so, why not also trust that server with storing the information about your supply chain?
I work in Azure, and my team builds the Coco Framework. There is more information on the details in the technical whitepaper here: https://aka.ms/cocopaper
Coco is designed for permissioned networks (as opposed to public networks). The network constitution in Coco contains a list, arrived at by a vote of consortium members, of all of the actors permitted to interact with the network. Coco implements network-level authentication to restrict access to participants. The constitution state is stored within the state replicated by the Coco Framework, so it is stored on all of the nodes in the network.
Beyond network-level authentication, there is also ledger and DApp level authentication. The supply chain demo demonstrates this capability. For the demo, we modified Ethereum to integrate it with the Coco prototype. We removed the capability to read raw transactions or to access raw smart contract state directly. Instead, the DApp must implement public smart contract methods enabling reads to state that the developer wants to expose. Those read methods contain code (in this case implemented in Solidity, executed by the EVM) that is responsible for authentication and authorization of callers. This enables the DApp developer to decide for themselves now to authenticate the caller, and what roles and privileges apply to the DApp's data. We also did some work to restrict access to events to only authorized callers - you can read more in the whitepaper on this.
We believe there's an opportunity for common patterns here (a la the ERC20 token standard), but these patterns can vary by ledger and by DApp. All of that is above the Coco layer. This is why the ledger (in this example Ethereum) matters. The ledger exposes capabilities that either natively, or through smart contracts, secure the data in the ledger. Coco's job is to ensure that ledger data is only ever in the clear inside the TEE, where the ledger and smart contract code can implement a confidentiality model appropriate for the use case.
First of all, I haven't read the whitepaper yet, forgive me
But if I understand what you're saying correctly, Coco develops a smart contract that implements some sort of authentication method such that it cannot be publically read on the Ethereum blockchain?
And that the ability for Coco framework to implement those permissions depends upon the ledgers capability? So for example, Bitcoin's scripting language wouldn't be sophisticated enough to support authentication via Coco? (amongst numerous other functions of course)
There are three layers at work in the confidentiality demo.
Coco is at the bottom of the stack. Coco handles replication of data across a network of TEE-enabled nodes, ensuring confidentiality and integrity of the data. The data is only in the clear inside each enclave. Coco enforces network-level authentication, restricting connections to actors authorized by the network constitution. At this level there are no smart contracts.
In the middle of the stack is the ledger. In the demo that is Ethereum ported to run on Coco. We disabled a few Ethereum APIs so that transactions and smart contract state cannot be read directly. We also added access control to APIs that expose events.
At the top of the stack sit smart contracts that are hosted on the ledger. Here the DApp developer can add public read methods to expose any data that they want to expose, and they can implement access control within these smart contracts to restrict access to appropriate counterparties. This can be based on RBAC with arbitrarily fine-grained rules.
In the case of bitcoin, some design would be required. Today, the scripting language is used to decide whether to unlock UTXOs at the time that they are consumed as inputs to a new transaction. If bitcoin were integrated with Coco, there would have to be some modifications made to apply access control somewhere. This could be done in the ledger code. For example, it could only allow read access to a given transaction by the counterparties (it is not obvious how the counterparties would be identified, but in the P2PKH case perhaps the caller could sign the request with the private key corresponding to the public key hash of either an input or an output). Or the bitcoin ledger could be augmented by allowing the creation of scripts to govern access. They would need to be accommodated in the transaction format and stored along with the ledger. This would be a bigger change obviously.
Coco enables the ledger to mask all data, including metadata precisely to prevent the leakage you ask about. When a ledger integrates with Coco it decides what capabilities to take advantage of - and how much data to expose to the public, to permissioned participants, to counterparties or to any other role. Similarly, when someone writes a smart contract on top of a ledger, they can take advantage of the confidentiality features to decide what to expose to their callers based on the role of the caller.
We are aiming to enable a decentralized system that behaves the way that enterprises expect the data layer should behave - to only expose data to authorized callers. The cool thing about it being decentralized is that you don't have to trust/pay any one party to run it, and your authorized callers can include many counterparties within a market.
Coco doesn't use any underlying network - it forms the bottom-most layer of a permissioned blockchain network. When a ledger (could be any ledger, Ethereum as in the demo or otherwise) is integrated on top of it, the ledger decides whether to expose metadata or not, and to whom.
I think the idea is that, since the blockchain nodes are running in a TEE, that any participant in the network can get an attestation to be sure that no one has tampered with the rules of the network. You don't need to personally validate each transaction as long as you are sure that the network is running the correct code.
It seems that permissions are set in each contract with identities tied to Azure AD members. I might be wrong about that. The white paper is pretty long and I only had time to skim it.
TEE is a joke. I don't even trust the newer SGX [1], which some blockchain companies like Corda [2] are adopting now, let alone TEE, with its myriad of security issues [3].
You captured the basic idea of the TEEs well. One way of thinking about this is that proof of work and proof of stake consensus protocols establish trust on a per-block basis. By leveraging TEEs, we have hoisted that trust establishment out of the per-block workflow and instead have the option to pay the cost once, at the time the network is established. One tradeoff of this design is that a TEE compromise would have major impact on the ledger. The whitepaper (https://aka.ms/cocopaper) contains a section on mitigating TEE compromise. Additionally, our intent is to support multiple consensus models, including models that require per-block trust validation. Ledgers and consortiums are free to make choices about what they want to support depending on their threat model and the assets being protected - with the ability to trade off scalability and latency against security as they see fit. What we demo'ed is one design that we think is interesting for many use cases we've heard about from customers.
Permissions are not tied to AAD members per se - we rely on a set of X.509 certs that correspond to the identities of the actors on the network for network-level authentication. These certs are referenced in the network constitution.
Ledger- and app-level authentication can be done however developers would like to do it. It can be, but need not be, AAD. See my comment above or the whitepaper for more details on the confidentiality design.
This is nothing that cannot be achieved by a write locked DB, with verification via inputs from smart contracts. You are basically using the security of these massive P2P networks to shore up a consultancy model.
Yeah, exactly. These permissioned blockchain implementations rely upon some centralised source of trust (eg the government, network permissions, etc.) and I don't see exactly what distinguishes them from a distributed ledger. The core innovation and the whole point of blockchains is that they are permissionless and trustless. Or am I missing something here?
Yes, the core innovation in public blockchains, the double spend problem in trusless networks, is not present in private blockchains and private blockchains can he simplified with basic block that have existed for decades.
The biggest and critical issue with private blockchains is at the political level: how to make a lot of parties (e.g. bank) agree in a protocol involving critical things (e.g. money).
Many use cases we encounter in customer discussions can best be solved by using traditional databases which benefit from academic and industry investment over more than 50 years. Databases offer more mature algorithms, implementations, toolsets, talent pools and ecosystems.
That said, there are some compelling scenarios that customers are exploring where a decentralized model opens up new market opportunities, or reduces risk or reduces cost.
One challenge with a database is answering the question of who operates it, and whether that party could choose or could be compelled to act maliciously. Coco and its ilk are specifically designed to address that concern, with tradeoffs in other dimensions as mentioned above.
I don't get it. Blockchains solve the consensus problem. If you use a TEE for consensus then you have no consesus problem and don't need a blockchain. You can basically choose any type of datastructure at that point.
We tried to address several separate concerns with Coco: scalability, latency, confidentiality and governance. TEEs can be helpful in addressing each one. We are working with ledger partners who want to use Coco to address some but not all of the concerns - for example they want fine-grained confidentiality, but they don't want to rely on the TEE for consensus. In this example Coco can be used with Proof of Work.
In the technical whitepaper, one of the things we discuss is that the "Ledger Model" (data structures, APIs, abstractions and programming model) are owned by the ledger, not by Coco. I think you are right that using TEEs opens up the alternatives to some of the data structures and abstractions in use in the public networks today. We look forward to seeing what people will do with Coco in this regard.
Think you have a lib of smart contracts like you have a lib of java code.
Part of your code is used internally and you have an authz server (typically not the one that runs the java code, in MS world it's active directory).
Think that you have dockerized your java servers. It's not that you don't trust your employee laptops for development, it's just that you want to reduce the differences between dev and prod.
Same for blockchains, you want a lib of contracts, you want authz, you want to reduce the diff between public and private.
Trying to parse through the buzzwords, it sounds like it's trying to replace the need for a traditional database for ledger applications.
Let's say you're a traditional enterprise and you have a ton of geographically dispersed operations. Retail has shops open in malls across the country, logistics has warehouses across the country, and so on. Each one of these places has a local ledger - how much product is on the shelves, what came in, what went out the door. Many times, the ledgers are related - what leaves a warehouse should arrive at retail, and not drop off the face of the Earth.
Traditionally, you had a centralized database to manage all of this, from which reports could be drawn and sent to management. The problem with having a centralized database, however, is that it's a single point of failure. The database can suffer a loss of availability, etc.
If you replace it with a blockchain, then you can get rid of the database and allow all of your geographically dispersed operations to manage the ledger in a peer-to-peer manner, without the security problems that used to dismiss p2p solutions for enterprise, because the blockchain ensures the security of the ledger. Blockchain contracts can allow, say, a retail outpost to contract with a warehouse outpost to receive a shipment, even without connectivity to central management, and then central management can track the activity after-the-fact when it updates.
The real question that enterprise blockchains have to answer is, "is it really worth it to dump a system that works most of the time for a benefit I rarely if ever need that'll cost the enterprise a small fortune to develop, or are we picking blockchains because they're fad of the month and people love resume-driven-development?"
The Coco team shares Richard's view that the distinguishing factor is where the trust boundary exists within the system. In the case of Coco, we assume a lack of trust among consortium participants, but we leverage the attestation and anti-tampering features of Trusted Execution Environments (TEEs) to establish trust between the enclaves: assuming that the TEEs themelves are trustworthy, the TEEs can provide cryptographic proof of the software and configuration running on each enclave. In other words, I don't trust you, but my enclave has decided it can trust your enclave based on mutual attestation exchange and mutual authentication. In other words, we've transitioned from a byzantine failure mode (adversary can replace the expected remote code with arbitrary code at will) to a crash failure mode (adversary can shut the remote enclave down at will, but not alter what runs on it).
Once there is trust between enclaves, Proof of Work seemed inefficient as a consensus mechanism, although it's certainly one choice that is available and that can be used with Coco (in this case Coco would provide governance and confidentiality, but scalability and latency would be limited by PoW). Instead we can use any one of many distributed systems techniques such as Paxos or Raft to achieve consensus.
This is an amazing development for enterprise as it removes the major risk of being cheated after the fact. This is largely why it's so difficult to establish trust between enterprises and had lead to this situation where the best trust is authoritarian centralization.
If we can lose this barrier to establish trust from a human one to a code audit that would be and outstanding achievement for our civilization.
Is there even a difference between a traditional distributed database and a blockchain once you remove proof-of-work? Without proof-of-work, the Bitcoin P2P network would just be a distributed database storing a linked list of blocks (each block pointing to the hash of a previous block), plus some business logic.
And on top of that, it sounds like Microsoft ditched most/all of the proof-of-work, because the nodes are trusted and the proof-of-work increased transaction times. So it sounds like whether Coco is actually a blockchain or a distributed database which has been branded as a blockchain because blockchains are FotM, is debatable.
We tried to address several distinct concerns with Coco: scalability, latency, confidentiality and governance. Scalability and latency are determined largely by the consensus model of the network. Our intent with Coco is to make consensus pluggable so that each network can make its own choices (via the Coco network constitution) about how to run their market.
I agree with you that the branding is tricky, in part because the dominant term "blockchain" is describing a specific data structure. The key point we wanted to convey with Coco is that we are trying to enable secure, performant, multi-party computation. We think there will be many models for this over time as TEEs come into wider use. "Blockchain" is just one of them.
The part of a block depending on the hashes of its ancestors seems very useful for tamper-evidence, which is useful in many applications if you can handle the data model & volume. Being able to definitively say who changed what and when is worth a lot if you have to maintain data which could be used in court and a distributed ledger, Merkle tree, etc. is more predictable and much cheaper to run if you don't have to maintain mining-level infrastructure.
I know I already replied but I forgot to mention another great usage of a blockchain: Logging. Not general-purpose logging, no. I'm talking about SOX-like "must be tamper-proof" transaction logging.
So say you've got central logging setup at your organization. You're smart and are using rsyslog with SSL/TLS and your own CA. For the most part you can reasonably claim that your log messages are secure from the server that emitted them to the destination in your central logging system but can you guarantee they're not modified after that? No. You can't.
From this perspective using a blockchain for logging security-critical events would be extremely useful. It would be impossible for an attacker to modify the logs after-the-fact so that you could no longer determine which account they used to login.
You wouldn't want to use it for general logging because of the overhead but for things like login events, reboots, etc it would be fantastic.
Logging requires high speed transactions. Blockchain is very slow. That is by design, so that any changes incur too high a price for anyone considering tampering with it. Every block header write involves solving a hash puzzle (i.e. mining), that in the case of Bitcoin takes on average about 10 minutes to solve.
A blockchain isn't as much of a guarantee as you think it is. Maintaining an offline, physical-access-restricted backup of critical logs is arguably more secure than a blockchain which can be altered by an attacker controlling the majority of the blockchain's computational power.
Will it? Half the point about how blockchains work is that dropping blockchains which are shorter than mainline is standard operating procedure and completely ordinary.
People holding cryptocurrency would notice an illegitimate takeover of the blockchain right away because they'd be trying to spend cryptocoin which, all of a sudden, they no longer have. But regulators aren't trying to tally up business inventory on their own ledger so that they can send it off to other parts of the business and all of a sudden that kind of logistics fails for the regulator because of what you called "funny business". A regulator is a passive observer, and a passive observer can't detect funny business without actively auditing the blockchain against their perceived notion of whether the current state of the blockchain is normative... which is a very difficult problem indeed to do at scale, one which regulators today haven't yet been able to really automate, even with the relative certainty of a database (which a regulator could order regular dumps of, for analysis, if it wanted to).
Googling for enterprise blockchain scenarios, I find https://www.hyperledger.org/projects/sawtooth/seafood-case-s... I guess in this case the goal is to ensure customers trust in the enterprise beyond just reputation. These records are currently being stored in traditional databases and the customers trust that the records aren't being tampered with out of the expectation of consequences if the enterprise was caught cheating. But, with a blockchain record, cheating becomes extraordinarily harder. The customers do not need to trust. They can verify.
While a 51% attack is a real concern, an even more likely scenario is the network going down. During a network split the local node(s) will happily continue to ingest logs which once the network is healed will all be rejected.
While I haven't had any real life interactions with these, I can think of a couple scenarios where it might make sense:
- Your company handles dangerous or highly regulated materials (prescription drugs, hazardous materials, etc.) and you are required to have controls in place to monitor your supply chain.
- You deal with lots of vendors of questionable reputation, or have a history of graft, embezzlement, or other loss in your supply chain. For example, easily "misplaced" goods like cigarettes that need to be distributed to lots of retail locations.
Health care: the network of providers and insurance companies need to share limited information securely. Right now it's completely ad-hoc and broken (I was billed $3000 for a cancer drug. I had the flu!)
Identity/reputation: If you have a certain reputation on eBay, you can't carry that reputation over to Amazon to sell goods. You must start from scratch. If the reputation score was independent of the service you could even post it on Craigslist and people could trust it.
Real estate: I paid a lot of money for a completely useless title insurance. If the details of a home title were stored on a blockchain, there would be no need for this entire industry of bloodsucking leeches. :)
Supply chain: there's an ad-hoc network of suppliers for many things (cars, planes, electronic doodads). There is no central authority, and it spans the globe. Having perfect knowledge of the supply chain can save companies lots of money. It's what made Walmart successful, now everyone can do it on a shared platform.
The tech for this stuff is still very primitive. I'd compare it to when Jaron Lanier started virtual reality in the late '80s. He was right but several decades too early. There are still some limited contexts where a current blockchain can be useful right now, but it won't be a big thing for a while.
Yes. Sprinkle a bit of blockchain pixie dust on your servers and now all of the sudden you can secure your data and go paperless. It wasn't possible before this. Software was useless before blockchain. Blockchain invented computers.
I think for large, dysfuctional corporations, it could potentially act as a single source of truth for certain data sets. In theory you could just use any database, but in practice a lot of times different departments get different setups from different parts of IT at different times. I work for a bank and our data is all over the map. I'd like it if everyone had to operate on and report from the same system, and that system was inherently auditable and unified.
The "single source of truth" is what people have been calling the Corporate Data Warehouse since the dot com era. The realities of that approach -- centralized gatekeepers, too hard to keep everyone on the same schema, different subgroups need different variations on the schema, slowness to iterate since everyone needs to accept the smallest change, etc. -- all those realities is what has largely given up on that Single Source of Truth vision in favor of microservices or data lakes or choose your buzzword du jour.
Blockchain solves problems around auditability, but it doesn't really solve the practical difficulties around the original CDW vision. If you weren't able to make a centralized data store work with a sql database, you're not going to make it work with a distributed ledger.
Yeah I think that's fair. Certainly the hardest problem is the human one. I don't think blockchain is a silver bullet, just maybe it will help. I wouldn't dump millions of dollars into it or anything without some sort of pilot / proven model.
>... all those realities is what has largely given up on that Single Source of Truth vision in favor of microservices or data lakes or choose your buzzword du jour.
>If you weren't able to make a centralized data store work with a sql database, you're not going to make it work with a distributed ledger.
The solution is clear: blockchain microservices. Each microledger is localized to the team using it, allowing for individual ledgers to be reused and composed to facilitate organizational agility across the enterprise. Stakeholder mindshare will soar.
Thanks, this helps answer the same question ("why not just any database?") when I read about it Walmart implementing a blockchain based solution to tackle food tampering.
Well, for a bank it can be super duper useful because it's "incorruptible digital ledger of economic transactions" (the very definition of a blockchain). So if you're transferring money from one bank to another it makes it all but impossible to mess with that transaction in flight (man in the middle attacks, timing attacks, replay attacks, etc).
Another example would be trades: Most people think of trades as buying stocks and bonds in an open market but there's a lot of private/internal-to-an-organization markets too. The blockchain is an excellent way to facilitate such transactions.
Being in banking (where we're trying to take advantage of blockchain transactions) the objections from management so far have been surrounding the inability to "undo" a transaction. Even though you can just make the same transaction in reverse afterwards the price of whatever it was that you're trading could've changed resulting in some troublesome circumstances.
For it to work you have to negotiate contracts ahead of time to ensure that all parties participating understand the ramifications of such a system. Since the blockchain is new technology it will be difficult to get 3rd parties to sign of on such things.
'because it's "incorruptible digital ledger of economic transactions" (the very definition of a blockchain)'
I would think that blockchain requires it to be a distributed ledger. A non-distributed digital ledger is simply a Merkle tree?
" So if you're transferring money from one bank to another it makes it all but impossible to mess with that transaction in flight (man in the middle attacks, timing attacks, replay attacks, etc)."
You can use non-blockchain cryptography to guarantee that.
> You can use non-blockchain cryptography to guarantee that.
Not in the same way though. An attacker could still modify the transaction after-the-fact at both endpoints during or after reconciliation processes (sadly, most banking transactions still happen in batch and there's multiple reconciliation processes every day). They could hack the reconciliation process(es) to undo or modify transactions later in the same day or--depending on the banks in question--days later.
Then there's also the possibility of just changing balances at one end of the transaction (flat out) with no way for the 3rd party to perform the equivalent of double-entry accounting to verify that the amount received matches what was sent. Bank transfer reconciliation catches problems like this all the time and it's baffling to me (but apparently has legitimate causes).
A blockchain would completely negate any such attacks and make reconciliation pointless.
> Well, for a bank it can be super duper useful because it's "incorruptible digital ledger of economic transactions" (the very definition of a blockchain).
If that’s the definition of a blockchain then it must include proof-of-work. Data doesn’t become incorruptible because you put it inside a block that points to the hash of a previous block.
I always wished airline/hotel "point" programs were blockchain based. This would instantly create a valuable secondary market for people to transact points for things. This will never happen, of course, because I assume the business model for those programs factors into account that only a small % of the awarded points are ever redeemed. (I remember reading this many times over the years, but don't have a reference.)
First and foremost: blockchain, in its essence, is a document timestamping
service. As such, it allows somebody reading it to tell the order of arrival
of stored documents (documents themselves being unmodifiable, as they are
usually identified by content in cryptography).
It just happens that ledger is a quite good fit for document timestamping, and
account balance can be used as a way to transfer money-like values (note that
it's not the only way; cryptographers have a history of developing digital
money systems).
About the only thing new about blockchain is that it doesn't need a trusted
third party (system with rights and means to modify the data) to timestamp
documents to defend against adversarial modifications to the timestamps
stream.
Anyway, anything that would use ordering of documents/messages could be built
on top of blockchain, but calculating proof-of-work is a very steep price to
pay for the defense against some of the participating servers being malicious,
given that enterprises happily trust regular databases that don't sign
cryptographically anything.
In theory, this benefits complex business processes running across corporations/agencies/gov/etc. requiring a distributed ledger. For example, mineral mining/procurement/certification/etc is a complicated lifecycle across many actors. I can't remember which podcast I heard it on, but the suggestion was anywhere there was a "clearing house" in use by multiple corporations for a particular process, there was an opportunity for blockchain/smart contract use.
In practice, I have yet to see anything concrete, but I haven't exactly been looking hard.
> In practice, I have yet to see anything concrete, but I haven't exactly been looking hard.
"In theory yes, in practice no" - sums up every explanation I've seen of whether blockchain technology could be applied to a particular problem. I still haven't seen a "killer app" that's not better suited to a traditional database.
Bitcoin became useful because it's an unregulated currency that has enough acceptance to be liquid and enough anonymity to be used for clandestine purposes. As soon as you try to use blockchain tech for "traditional" transactions you end up eating the computational cost of a distributed ledger for no apparent benefit.
In between different companies, I have seen some dumb implementations of an "electronic signature" (both homebuilt and using decrepit, ancient technology). Having one universally-adopted tool for establishing trust between parties, whether that's medical patient information, contract work, or supply-chain handoff could be revolutionary.
We did a POC for shareholder voting for the Indian stock exchange.
Auth is handled by the stock exchange and votes / proxies are handled on the block chain portion.
I wasn't involved in the project, but it seems like the primary benefits are public auditability and the immutable nature of the transactions were the value drivers. As implemented, full trust is placed in the (non block chain) central exchange for initial vote assignment and all auth.
I don't understand 'enterprise blockchain'. Doesn't a blockchain depend on thousands of computers, each independently verifying the data? How does this hold if the blockchain is just running on 1 server (or a few, but that's not the point)? Then it's just a server, not a block chain...
You're right: It's not practical to run a blockchain on a single server or even just a collection of servers. For it to work properly it needs to be constructed as a P2P system. So each system that wants to use the blockchain has to participate in its construction.
What this framework appears to do is enable your endpoints to participate in a one-way fashion. So they will get just enough information to facilitate a transaction but nothing beyond that.
It seems like a bit of cloak & dagger tomfoolery where the blockchain is just being implemented behind-the-scenes on a specified collection of servers but I haven't looked very deep yet. I can see the benefit to Microsoft from having a setup like that--they can allow customers to participate in a blockchain-utilizing system without giving them full access to the blockchain but to me that seems like defeating the purpose and unnecessarily trusting a 3rd party to handle all your transactions with no independent way of verifying said transactions.
In other words, it's no different than just standard server-client architecture except instead of handling transactions through a database (the traditional way) they utilize a blockchain in the background. When you want to verify a transaction you're really just making a request to their central server and asking it to do the job for you--and trusting whatever it tells you.
> It seems like a bit of cloak & dagger tomfoolery where the blockchain is just being implemented behind-the-scenes on a specified collection of servers
The key is who is running that "specified collection of servers". If they're all yours, then yeah, there's no advantage to just running your own sql-ish cluster.
However, what if now your p2p miner pool includes a few machines run by your regulator? Yes, your business logic endpoint nodes are participating in a one-way fashion, but their transactions are now being automatically logged by the regulator (regulator doesn't need to know what the underlying business logic is, just that the reportable transaction results are being logged in the blockchain they're part of). Something like a third of financial firms' business is around reporting requirements.
Or consider a large supply chain... again the miners aren't just one company, it's everyone in the supply web or the consortium. Allows for coordination without necessarily being open to the public.
The technical whitepaper clarifies some of these points. To summarize, Coco networks are permissioned. Every authorized member can run a node, and all nodes see all data on the ledger. The code running inside of TEE-protected enclaves on each node determines what subset of the ledger data to expose to each caller, based on the permissions they are granted. Coco enforces basic network-level authentication, but the ledger and the smart contracts on the ledger enforce all of the app-level authN/Z.
>This is because existing systems were designed to function—and to achieve consensus—in public scenarios amongst anonymous, untrusted actors with maximum transparency. Because of this, transactions are posted “in the clear” for all to see, every node in the network executes every transaction, and computationally intensive consensus algorithms must be employed. These safeguards, while necessary to ensure the integrity of public blockchain networks, require tradeoffs in terms of key enterprise requirements such as scalability and confidentiality.
..
>Coco achieves this by designing specifically for confidential consortiums, where nodes and actors are explicitly declared and controlled. Based on these requirements, Coco presents an alternative approach to ledger construction, giving enterprises the scalability, distributed governance and enhanced confidentiality they need without sacrificing the inherent security and immutability they expect.
It's useful when there's a consortium of companies who want to agree on some flow of transactions, but don't want to trust or pay any one company to maintain an authoritative database.
(This assumes the public chain is unsuitable for scalability or confidentiality reasons.)
Their parallelized data warehousing solution: Azure Data Warehouse.
Their document store database: Azure DocumentDB.
Their large scale structured+unstructured data storage and analysis (frequently referred to as a data lake): Azure Data Lake Storage... AND Azure Data Lake Analytics. Let's talk about the precise differences and co-dependencies between these two.
Their offering to expose functions as an API: Azure Functions.
Their RDBMS, a product that runs as a server and is queried with the language, SQL (what might, in another world, be called a SQL server): SQL Server.
Their cloud version of the same: Azure SQL DB.
Their only well named product, you ask? Their cloud platform named Azure, which is the color of a blue sky. Well played, Microsoft.
Are we running out of words, or combinations of letters that are pronounceable? I swear to god this is like the third time I've seen someone release a new framework that had the same name as a different, already popular framework.
Sure, Apple's API is called Cocoa, but verbally is there really any difference?
I was just going to say, verbally Coco = Cocoa. Not that it matters all too much since they're in different spaces, but they could have come up with a different name, especially when you don't even have to use a real word.
Is this Microsoft's subtle way of saying they do not ackknowledge iOS's Cocoa and Cocos2d frameworks? Or were they hoping dropping the 'a' wouldn't cause for confusion/overlap.
He makes it sound like all your interaction with Ethereum goes through the Coco framework (so permissions are implemented by Coco deciding which contracts you're allowed to see). Is that right?
If so what's the point of using Ethereum at all?
- Who is doing the computation for a smart contract if it's private and only you can see it?
- Is the permissioning managed by a trusted Coco server somewhere? If so, why not also trust that server with storing the information about your supply chain?
[1] http://aka.ms/cocodemo