Subject: [Din] Databases vs. ledgers for infrastructure

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 Feb 2018 17:20:32 +0000

Greetings. In prepping for our upcoming meeting, I was re-reading the charter and find that a lot of it is about ledgers, particularly blockchain systems. However, I am being uncreative and cannot think of any use cases for infrastructure needing to see a local copy of a ledger, just needing to see the current state of the database. Of course, people making policy for infrastructure get value from ledgers or a time series of database snapshots

Do we have a list of use cases where the infrastructure itself needs to have a ledger in order to act without human intervention?

--Paul

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 4 Feb 2018 08:21:41 +1300

> Do we have a list of use cases where the infrastructure itself needs to have a ledger in order to act without human intervention?

I think that will depend on what some particular infrastructure component is trying to do. Just let me wave my hands a bit: consider a node that is trying to diagnose a problem with a particular IP address. If it includes an AI component or just some clever heuristics, it might need to know who was using that address two days ago. Did that address get black listed, for example? We don't want to rely on a centralized database for this, because that's also a centralized single point of failure.

More generally - if we're going to distribute management functions, we potentially need to distribute management data too, for both speed and reliability.

    Brian

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Mon, 5 Feb 2018 13:57:01 +0100

Generally speaking, I'd say it depends on your trust policy. If you 
trust all the nodes inside your infrastructure, just put the ledger on 
one of them and let the others query it. If you are concerned that a 
node may be compromised, put the ledger in all the nodes, so they can 
detect undesired modifications.

Regards,

Jordi

El 03/02/18 a les 20:21, Brian E Carpenter ha escrit:
> _______________________________________________
> Din mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/din

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 05 Feb 2018 15:23:15 +0000

> Generally speaking, I'd say it depends on your trust policy. If you trust
> all the nodes inside your infrastructure, just put the ledger on one of
> them and let the others query it. If you are concerned that a node may be
> compromised, put the ledger in all the nodes, so they can detect undesired
> modifications.
> 
there was this cool old protocol suddenly occured to me we could
revisit w.r.t standards for blockchains, maybe:
https://tools.ietf.org/html/draft-mrose-blocks-architecture-01
>         Greetings. In prepping for our upcoming meeting, I was re-reading 
> the charter and find that a lot of it is about ledgers, particularly 
> blockchain systems. However, I am being uncreative and cannot think of 
> any use cases for infrastructure needing to see a local copy of a ledger, 
> just needing to see the current state of the database. Of course, people 
> making policy for infrastructure get value from ledgers or a time series 
> of database snapshots
> 
>         Do we have a list of use cases where the infrastructure itself 
> needs to have a ledger in order to act without human intervention?
> 
>     I think that will depend on what some particular infrastructure 
> component is trying to do. Just let me wave my hands a bit: consider a 
> node that is trying to diagnose a problem with a particular IP address. 
> If it includes an AI component or just some clever heuristics, it might 
> need to know who was using that address two days ago. Did that address 
> get black listed, for example? We don't want to rely on a centralized 
> database for this, because that's also a centralized single point of 
> failure.
> 
>     More generally - if we're going to distribute management functions, 
> we potentially need to distribute management data too, for both speed and 
> reliability.
> 
>          Brian
>