[Bucardo-general] Automated Trust: Database Meets Blockchain

[John Olsen]

Hi,

On reading through the "bucardo" file on github, I can see that my ideas
would mean fundamentally altering Bucardo.

If these ideas gain any creedence here, I am proposing to create a new
adapted package called "Bucordo" to reference the idea of an ordering
process (the transaction ordering to form a block, that will be necessary)
but to relate to bucardo, still,  as an ancestor.

John.

On Mon, Jul 4, 2022 at 10:18 PM John Olsen <john at itotchaincloud.com.au>
wrote:

> 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/36b7f127/attachment-0001.htm>