[Bucardo-general] Automated Trust: Database Meets Blockchain

[John Olsen]

I have decided to shut down all github repositories and we are moving to
Atlassian Bitbucket

Therefore the new url is

https://bitbucket.org/itotcca/bucordo/src/master/

This remains a public repo.

John


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

> Hi,
>
> I have established a forked repository for my project "Bucordo".
>
> It is at
>
> https://github.com/john-itcsolutions/bucordo
>
> Cheers,
>
> John.
>
> On Mon, Jul 4, 2022 at 11:51 PM John Olsen <john at itotchaincloud.com.au>
> wrote:
>
>> Once again,
>>
>> I'm not exactly as expert as some in Perl and Postgres, however I am
>> prepared to do as much as I can to achieve this goal and to "open source"
>> it.
>>
>> The use of the Elastos Smartweb blockchains and system is our company
>> idea and need not be carried across (at least I don't think so) to general
>> usage.
>>
>> Anyone interested?
>>
>> My linkedIn is:  https://www.linkedin.com/in/john-lloyd-olsen/
>>
>> John
>>
>> On Mon, Jul 4, 2022 at 11:25 PM John Olsen <john at itotchaincloud.com.au>
>> wrote:
>>
>>> 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/20220712/b650adfb/attachment.htm>