[Bucardo-general] Automated Trust: Database Meets Blockchain

[John Olsen]

Hi again

I have been thinking further on this subject.

It appears it would be essential to organise inter-master replication via
the Bucardo masters so that an event originally may occur on base-server-0
then it would communicate with bucardo-server-0 which would communicate
with every other bucardo sevrer, which would then cause their own
base-servers to be updated, and some time after this, enter into an
ordering process (between the range of bucardo-servers) of a Block of
transactions for committal. In this way bucardo servers only update "their
own" base-servers unless the bucardo server is updating other bucardo
servers on behalf of the base servers.

John Olsen
IT/OT Chain & Cloud Australia

On Sun, Jul 3, 2022 at 2:31 AM John Olsen <john at itotchaincloud.com.au>
wrote:

> Hi everyone,
>
> I initially sent emails elsewhere until I found this list. I am copying
> them here. The comments are in relation to an IBM Article from IBM India in
> 2019 to be found at
>
> https://arxiv.org/pdf/1903.01919.pdf
>
>
> "
> Yes, Ben, I am searching for multi-master replication solutions, but with
> a difference .. the idea is to allow automated Trust to be developed on a
> database system by doing away with your standard single superuser system on
> bucardo and replacing it with multiple bucardo masters on top of multiple
> substrate masters..
> My idea is to copy IBM's research and to build-in a consensus-seeking
> solution for the proposed multi-master bucardo system. The consensus being
> sought is intended to order transactions appropriately before final
> committing..Please refer to the previously attached IBM research paper"
>
> "
> Sorry to carry on before receiving any response, but I have been thinking
> about how to implement these Automated Trust ideas.
>
> If there were as many bucardo servers as there were base-level database
> servers, and each bucardo server were configured to only replicate from
> changes on its own (base) database server, then the problem would reduce to
> obtaining consensus (per transaction "block") from all bucardo servers as
> to the order in which the executed transactions are to be committed. The
> Consensus Algorithm outlined in the IBM paper, is given in sufficient
> detail to reproduce on bucardo (I claim!)
>
> I am now thinking I should look at your github site.
>
> From our point of view as Enterprise Application developers and operators
> we are looking toward customers such as those companies involved in Supply
> Chain operations which require smart contracts you can implement on
> postgres databases, if bulk data is involved. Also we intend to provide
> distributed applications in non-internetworked areas eg Real Estate
> Agencies, NGO Housing Providers, Conveyancing etc. We organise our
> customers by "Member Class" meaning they would share IT "Mission" and a lot
> of activities daily (as far as what was actually done during the day) and
> fit into the same business network (if internetworked at all). One member
> Class per database server. Operated by a consortium-employed operator - a
> consortium of Members (Companies) in the Class. Our only involvement as a
> player, is to have the numbers of users etc etc reported monthly for
> Billing purposes. The idea that nobody has to trust anyone else during
> daily operations is attractive. Member Class Operators are being kept
> honest by the nature of the system, as are we. That is why I am hoping we
> can somehow organise an adaptation to bucardo for these purposes.
>
> It is worth noting that we are looking towards the Elastos Blockchain with
> its "Carrier" security system for web communication as the provider of
> "Distributed" Id's to allow signing of every transaction securely The only
> thing in the IBM agenda of shortcomings of databases (from the point of
> view of a Blockchain) is how can we make a PLpgSQL function as
> "deterministic" as a transaction on a blockchain? We could also possibly
> utilise the insurance of Elastos to check the database for integrity (as,
> if more than 50% of bucardo servers were somehow caused to act fraudulently
> in concert, Trust would be destroyed).
> "
> We think this is a very attractive idea of IBM's and feel that bucardo
> could play a role in its development. bucardo would act both as replicating
> agent as well as ordering agent.
>
> John Olsen
> IT/OT Chain & Cloud Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://bucardo.org/pipermail/bucardo-general/attachments/20220704/e9f1a004/attachment-0001.htm>