[Bucardo-general] Automated Trust: Database Meets Blockchain

[John Olsen]

Hi once more everyone,

You may be wondering how we get "Automated Trust" from such an arrangement.

It appears to me we would have to insist that database administrators as
much as developers be denied permission to write anywhere to the production
databases and that we provide (as ITOTCCA) only ways for client devices to
update the database including signing up new customers and creating new
member-classes (performed by ITOTCCA's own database node (our own
member-class)  servers via our own client devices). In this way each
transaction can be signed with an Elastos-created DID and therefore becomes
"Non Repudiable".

John Olsen
IT/OT Chain & Cloud Australia

On Mon, Jul 4, 2022 at 11:52 AM John Olsen <john at itotchaincloud.com.au>
wrote:

> 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/0150c2a8/attachment-0001.htm>