W3C home > Mailing lists > Public > public-blockchain@w3.org > July 2017

Re: Blockchain community- today's minutes

From: benedikt herudek <benedikt.herudek@gmail.com>
Date: Wed, 19 Jul 2017 11:08:42 +0200
Message-ID: <CAHwTpXrsA7w0tUKqjAJu1TGnzkXvQ3ADP5pEQtzR0aYwtfOUhA@mail.gmail.com>
To: Colleen Kirtland <cskirtland@yahoo.com>
Cc: Blockchain CG <public-blockchain@w3.org>
Hi,

I would suggest next to a taxonomy to try to formulate decision criteria,
when Blockchains are a good idea. With the amount of marketing and hype
'cutting through' could be a useful contribution.

Not an easy task, below my stab at it - also in the (outdated?) google doc.

regards

Benedikt


List of criteria for using Blockchains

The following list of criteria shall help to decide, if the use case is
suitable for a (shared) database or blockchains:


   1.

   Are there different entities (persons, departments, corporations,
   authorities) which have their own versions of facts in separate means of
   recording like databases?

Counter example: You write a diary with your own highly and highly
confidential view

   1.

   Do you need one common version of the truth, e.g. a shared database,
   into which several entities read and write to work efficiently ?

Counter example: You work in a conglomerate in different geographies with
highly

separate business units. Coordinating for finance reporting via

conventional exchange of aggregated data is sufficiently efficient

   1.

   Is there potential for meaningful and consequence bearing dispute
   between these entities about what the ‘truth’ (status of the database) of
   this shared database could be ?

Counter example: You work in a conglomerate in different geographies with
highly

separated business units. Coordinating for finance reporting can be

done via conventional exchange of aggregated data

   1.

   Is engaging a trusted intermediary to settle disputes not feasible for
   e.g. economic reason or lack of such trusted middlemen ?

Counter example: You are working in an environment, where trust in
goverment or

organisations like banks is low due to corruption or lack of resources

of those intermediaries and costs might be higher than benefit.

   1.

   Instead of appointing one trusted intermediary are you able to describe
   a set of entities and consensus based and automated process to come to a
   conclusion which transactions will be allowed to be recorded into the
   central blockchain?

Counter example: You have a very small set of collaborators the majority of
which you

either do not trust or do not have a proper internal reporting or

technological means to participate in such an automated process

   1.

   Can you set up a governance to follow up or enforce implications of
the consensus
   status of the Blockchains.

Counter example: You set up a Blockchain Consortium between vendors &
suppliers of

natural resources but the homestates of major players in the

consortium do not have legal nor economic agreements with your

jurisdiction

If any of these criteria are not fulfilled, a Blockchain might not be the
right Design.

A connected ‘softer’ criteria is linked to your design of transactions and
the Blockchain.

   1.

   Can you describe simple, e.g. time-bound material relations between
   transactions which can be reflected in the ordering and linking of
   transactions

Counter example: You setup an identity registry, where profiles are
recorded separate of

each other, e.g. a mother of a son could be recorded after her son and

there is no link between the two


regards / groetjes / adios  / gruesse

Benedikt Herudek

On 12 July 2017 at 17:24, Colleen Kirtland <cskirtland@yahoo.com> wrote:

> Thanks to those who joined!
> The only action item out of today's meeting is that Michael Palage and I
> will continue to work offline to move the needle forward on the online
> Blockchain Use Case taxonomy.  Michael will be leading the vetting of our
> current taxonomy to ensure that terminology is standardized.
>
> We will keep the team updated.
>
> The next US based call is in 2 weeks.
>
Received on Wednesday, 19 July 2017 09:13:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 19 July 2017 09:13:29 UTC