20 comments

[ 4.8 ms ] story [ 46.1 ms ] thread
If it is a DLT without blockchain is it DAG based or something else like maidsafe? Please a quick tldr on what the tech is on the homepage would be great
It's something else - a new consensus algorithm, called Tempo. In one sentence - it's reactive, rather than proactive, therefore easily scalable. Based on the passage of logical time, but there's of course much more detail to it.
Here’s a whitepaper on the underlying technology:

https://docs.radixdlt.com/alpha/learn/whitepapers/tempo

The conclusion in the paper:

“This paper has proposed a method for determining total order of events within a distributed system, without relying on trust, that is scalable, efficient and agnostic to its operating environment. To reduce overhead and increase performance, our solution defines a structured, shardable architecture that limits state transfer information to only members of the network that need it. A peer-to peer network provides the means for communication and information routing via a reliable and robust gossip protocol. Nodes maintain a logical clock when witnessing events and periodically produce a tamper-proof commitment representing those events. When witnessing events, nodes collaborate to create Temporal Proofs which contain verifiable space-time coordinates which are used to construct vector clocks and determine when an event was first seen by the network. Nodes can join and leave the network at will and rely on detectable consistency anomalies to synchronize and bring them up to date.”

The periodically produced commitment log is done with a Merkle tree.

"verifiable space-time coordinates"

no easy task in a world of GPS spoofing and NTP attacks...

You don’t need verifiable time-space coordinates. You just need the topology of connections. We came up with largely the same thing two years ago:

https://intercoin.org/technology.pdf

We call it the Permissionless Timestamping Network and it is one optional component of a cryptocurrency system - but can be used for tons of purposes and is very easy for anyone to join. And since all connections are voluntary, there is no question of overwhelming any nodes either. Pure win :)

An updated whitepaper, covering the consensus in much more detail is coming in the following weeks. Happy to link it here for review, once it's ready.
We should wait the peer reviews.
I quote the founder of ethereum(one of the very few people I trust to actually not be scammer and be level-headed about blockchain stuff):

>Right. The claim that a mere DAG structure can solve the scalability trilemma is very false. You need to find a way to ensure that not every node needs to verify each transaction.I don't understand why they can't just group transactions into blocks and then have the DAG structure be over blocks, letting clients verify individual blocks with fraud proofs and data availability proofs. That would give them quadratic sharding right there.IMO the desire some people have to make "blockless" consensus algorithms is a huge mistake and step backwards; the way to get scalability is to have more layers of packaging.

>In a sharded chain, scalability of data[storing all the tx data] is going up a lot, scalability of computation[validating all income transactions] is going up but less than scalability of data (and additionally, sharding inherently makes latency of computation go up[nodes must communicate more]), and scalability of state[part of validating transactions - every node must know if a cross-shard tx is valid] is, in the current designs, not going up at all.

Looks like radix is addressing the data salability issue here, and maybe computation. Salability of state - not sure how this is addressed, if at all(will state be sharded as well?). There is nothing magical about DAGs vs blockchains.

Their webpages and whitepaper are so full of buzz terms that its hard to understand what they are actually doing. Some things are too high level, others are too dumbed down. All sorts of crap about atoms and constraints. 0 relevant explanation as to how it solves scaling better than ethereum's plan.

Also what is up with all the hyperbolic claims? 17 sextillion shards? Why would that ever be a good idea? How would you even start to maintain state across that? My BS detector is beeping.

Scalability of state seems to be addressed by minimizing the need for nodes to retain the full state, and the main mechanism is shards. From whitepaper: “A further benefit is that any Atom that performs an inter-shard transfer is present in both the previous owner's and new owner's shards. This, in part, eliminates the need for a global state and mitigates any expensive inter-shard state verification operations needed to prevent "double spends".”

I’ve only skimmed the whitepaper and the consensus check against conflicts seems to be a series of methods with escalating computational cost. I think they assume Atoms (e.g., Transfer Atoms) won’t grow so big that they span massive numbers of shards.

I agree about the proliferation of buzzwords. Why not use Ledger instead of “Universe”?

Not sure how the eventual consistency model works in an economic context, although that’s how ATMs work.

Sharding in this context is different from the sharding Vitalik is talking about.

In their whitepaper, they're talking about splitting up the state storage so that nodes don't need to retain the full state.

However, Vitalik is talking about splitting up the computation so that all nodes don't need to verify every single transaction.

ETH 2.0 (or Phore Synapse which I work on), splits the chain into many different "shards" which are basically lower-level blockchains. Then, validators get assigned various tasks to validate these subchains. (Verify these 50 blocks are valid). There are also mechanisms for ensuring that somebody stores blockchain history/state for a certain amount of time (proof-of-custody).

Well I don't know why you would trust anyone in the crypto world not to be biased towards their own project. I think Vitalik is shilling Ethereum pretty regularly while dissing other projects.
A Radix tree is definitely the right way to go, something we've been doing for years (gun.eco/docs/RAD).

They seem to be claiming global consistency tho, which is a much harder claim to achieve especially if you're heavily sharding. Worse if you are in a trustless system. Any fast answers as to what the solution is here?

I don't think there will be any useful answers, fast or otherwise, until a definition of the term decentralized is settled on which incorporates a fundamental requirement that the system so labeled be always tending toward greater decentralization by default, rather than (as most systems do, all blockchain projects included) tending to converge toward centralized leverage over time.

the key seems to be that there has to exist, on the part of all members of the group seeking to collectively optimize their behaviors to foster some shared set of values, an established and non-negotiable priority of decentralization over (even at the expense of) every other value (cost, speed, personal gain). Inevitably this priority becomes compromised as decentralization is 1. a poorly defined value to start with and 2. accrues benefits that are local to the group but non-local to its individual participants. As the group grows this dilution of its value, manifest as an increasing remoteness to the interests of each individual it depends on for support, becomes a hindrance to its support vs., say, transaction speed or cost or personal gain.

one of the very rare nontrivial examples of such a system would be the pre-capetian custom of equal division of estate inheritance in Merovingian France, vs. the primogeniture commonly practiced nearly everywhere else. And this too eventually succumbed to its own success, as the frankish state was "decentralized" due to this custom, its identity dematerialized and its integrity made vulnerable to regional rivals.

Just dropping in to comment on the 'light on details' whitepaper - the team is currently working on an updated Tempo whitepaper, covering the consensus in much more detail.