all 2 comments

[–]SoCo[S] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (1 child)

This article gives a breif overview of how the RLN design originated and links to a lightly, but sufficiently detailed, whitepaper outlinng it's design (as of the time of publication, Dec 2021?):

https://setl.io/the-regulated-liability-network-rln-whitepaper-on-scalability-and-performance/

The White paper:

https://setldevelopmentltd.box.com/shared/static/18mff2m990qabgzseiex3h7itq7qdnls.pdf

tl;dr: The white paper gives continuous silly jabs at cryptocurrency, but outlines their middle-ware cloud database partnered with AWS.

It fully trusts the system's member parties and does no verification, so it has a "very straight forward" approach to participation, while "[o]ther blockchains seek to strictly codify approval parameters."

A permissioned trusted system's simple consensus by blindly allowing its trusted members' to decide simple acceptance or denial, which isn't really "is orders of magnitude more efficient than proof-of-work or proof-of-stake"; it simply provided a different much much more trivial, almost non-existent, task.

By being a simple cloud database, with no actual consensus or trust-less security security to worry about, it doesn't need to provide the massive and valuable function of security, so "[B]y reducing the redundant compute tasks of the participants, by avoiding wasteful consensus methods", it will have a "small energy footprint", mostly the same 2K skyscrapers, 20K brick and mortar banking buildings, and 200K workers driving to work daily, which far exceeds anything any crypto blockchain's security producing mining outputs by miles.

They are using Apache's Kafka middle-ware (over TCP), which it claims is much better than how, "[m]ost blockchains connect nodes using raw tcp – the internet equivalent of a single phone line."

[–]SoCo[S] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 1 fun -  (0 children)

I got side tracked with the silliness and had meant to describe how it uses blockchain concepts. For the most part, it seems to only to do so superficially, based on the linked whitepaper assessment.

It proposes to use public/private key cryptography and have trusted members of its network sign transaction proposals and acceptances. This is a huge step up by its self, so please welcome the banking industry into the 1990's and late 1980's!

It groups multiple transactions into what it calls a "block." These transactions are meant to be kept together and executed at the same time, more like a transaction with multiple inputs/outputs. It's not clear if more than one "package" of transactions will be included in each "block."

One authoritative "sequencer" seems to be the plan to read the middle-wear queue and determine the order of transactions/transaction proposals....

...So it side steps the single most fundamental aspect of blockchains that extends to dumb cloud databases...the ability preform distributed consensus on block order and thus transaction order and timing. Deciding what transactions came before others is a huge deal for large distributed systems and the block chain consensus mechanism solves that issue by having the longest valid chain be the authoritative block chain, which establishes transaction timing and order between multiple decentralized nodes competing to establish this order. In cryptocurrencies, they compete by mining, but the act of mining is just a security aspect. In a permissioned system, several "sequencing" nodes could compete to establish the longest chain and instead employ a "no after...oh, no no, after you", approach.

They then take these "blocks" of transactions, ordered by a central authority based on middle-wear queuing order, and for some reason build them into a chain of blocks by hashing each with the previous. These are then store into various cloud databases they call "persistence". They maintain a persistence database store to access "proposed" transactions and for settled transactions, as they figure the permission-ed banking entities, who decide accept or reject a proposed transaction which they are on at lest one side of, may want to consider the pending transaction proposals as well for their decision.

This article showed that their permissioned cloud database application seemed to go out of its way to use a blockchain concept or two, mostly in name and barring aspects not addressed in the document, did so without the actual need of those concepts that came close to blockchain technology.