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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 >>> >>
_______________________________________________ Bucardo-general mailing list [email protected] https://bucardo.org/mailman/listinfo/bucardo-general
