Performed a record breaking test this morning with Cassie, the Radix research network.

80,000 transfers per second PLUS 100,000 pool swaps per second = 180,000 total transactions per second.  Clocked in 200,000,000 combined transactions in 18 minutes.

Network comprised of 64 validator groups, each with 8 validators, spread across multiple continents.

Each machine spec was 4 core CPU, 8 GB RAM, SATA SSD.

1M TPS+ community powered test not far away now.

Video from a Radix community member during the testing.

https://www.youtube.com/watch?v=a7DdpGybIp8

Over the past couple of years, I've been working away on a research network named Cassie which will lay the groundwork for the Radix network upgrade, Xian.

Cassie exhibits a number of novel and interesting properties, but the core goals were to implement a linearly scalable consensus protocol which also retains high decentralization and security metrics.

Linearly scalable in this context means that if the compute (validators) available to the network doubles, then the maximum throughput of the network also doubles.

This has been tested extensively, both in the "lab" and with members of the Radix community participating in the tests and we have achieved great results so far sustaining 120,000 transactions per second (about 50% being complex smart contract calls such as swaps) and consumed bursts of 160,000+ without issue.

Our plan over the next few months is to run a series of tests with a goal to exceed 1,000,000 transactions per second for sustained periods of time.  This will require significant compute hence my call out across crypto in general for participation.

We could of course simply rent compute from the various cloud providers and do the test ourselves, but my desire here is for these tests to be as representative of main-net performance as possible.  

That requires that we (Radix) should run a minimal amount of validators to bootstrap the network and the rest provided by 3rd-parties.  The validators would then be globally distributed, different hardware configurations & ISPs (we've had some guys use Starlink successfully at high load!) and behave akin to a main-net in the wild (minus the value of course).

Too often these "tests" are performed in a "lab" environment, totally under the control of the project stakeholders, run for short durations typically minutes, very simple transactions such as A->B transfers, high specification hardware, super fast connection & low numbers of validators.  

In some cases, critical elements have been disabled such as signature generation & validation in order to push the numbers.

These results are then paraded as if they are some kind of achievement, but upon main-net launch the performance capability is a fraction of what these tests achieved.  It is disingenuous, dishonest & unhealthy, distracting from legitimate projects who are working hard on real scalability solutions.

We want to do it right!

If you'd like to participate, please send me a DM.  You will need a machine with the minimum specification of 4 core, 8GB, 200GB SATA SSD & 20Mbps/50Mbps. If you have better specification hardware then you could run multiple validators on the same instance.

Also interested in any suggestions to ensure these tests as are real world representative as they can be.

Thanks in advance, and I look forward to busting some records with you all!

Also interested in any suggestions to ensure these tests as are real world representative as they can be.

Thanks in advance, and I look forward to busting some records with you all!

There's a 3rd reason for that patent that everyone misses...it's called a pinch, and is probably the most important of the 3.

Assume that our patent ISN'T granted.

Later some bank, or corporation, files a patent that infringes on our tech, and it DOES get granted.  It happens, maybe they worded something slightly differently, had better lawyers due to more money, etc

Then they decide "Hey, lets go sue those Radix guys and destroy the business they have built, cus, y'know, we own their tech now!"

So they come along with a law suit and they have us dead to rights...

But they don't, we can show our patent submission and it's refusal.  So if we really are infringing on their patent, then our patent should have been granted as it has an earlier date and theirs should have been refused.

Law suit dismissed!

With so many banks and corps filling patents and getting them granted, with tech that is arguably public domain in some cases, it made total sense as a defense.

I don't know why so many people have an issue with the patent, it's clearly defensive and allows us to monetise the tech to continue development long term from private licenses, regardless of the open source status for public, non-profit deployments.

That's just the start of our scale testing.

Next week we'll be adding more nodes, enabling sharding and shooting for 1 billion in 7 days or less.

From there we'll just keep scaling up the tests with more nodes and higher throughput.

We ran at a sustained 5k+ a few days ago in a short test...hardly broke a sweat.  More and higher load tests are coming, including a pub test net.

Everything else is futile if the technology ultimately can't scale.

We aren't concentrating on just scalability.....its a key part yes, but not where all of our focus is.  Security, efficiency, usability, infrastructure integration etc are all important things ONCE you have the scale nailed.

Perhaps you're thinking about other projects mentality....would be very naive to think there are NO issues lurking in there!  We have a number of auditors pending to code and security review once the final bits of the core are done.

Makes no sense to do that while we're still fine tuning things now the main R&D is done.

It could indeed!

We plan to do public testing that hits that (and beyond) over the next few weeks.

Challenge 3

Because Tempo operates with relative time, not absolute time, nodes stick to a "I'll keep what I've witnessed unless proven otherwise" and even then, their logical clocks still count up.

For example, say Node(A) witnessed an Atom(x') at LogicalClock(5), then it received a conflicting Atom(x) that supposedly happened before.  It doesn't matter what the time stamp on those Atoms are, it will always reference its local ledger first to discover information that it can verify against.  For Atom(x) to be proven to be before, then it must have in it's ledger some information about Atom(x) where the logical clock value is less than 5.  If it is proven that Atom(x) was first, and is accepted by Node(A), its logical clock will still increment and it will keep a record of Atom(x').

This is where commitments come into play and why reliable gossiping is important, as a node never "takes anyones word for it".

For Node(A) to alter its ledger, accept Atom(x) and disregard Atom(x'), it must have a commitment containing Atom(x) in a Temporal Proof that it saw BEFORE Atom(x').  If, when Atom(x) is presented with commitment "proof", the node can not find the commitment hash in its ledger that should have been previously submitted, it assumes that Atom(x) was created in a faulty manner.

Because of the inability to tamper with the commitment sequence, Node(A) will not have such a commitment, otherwise it would discover Bob's scam.

The paper details that Node(A) will also contact a number of its neighbours to perform a more intense order determination.  This will also fail, as none of those nodes will have any commitments in their ledgers either that match the supposed "proof".

Bob could continue to create a sequence of Atoms, TPs and commitments independently, even sniffing legit Atoms from the main-net in order to try and increase the viability of his "proof" and then submit them all in one go.  It is still detectable that Bob was faulty or dishonest as no node will have any commitments from Bob since before Atom(x') and Atom(x) were created.  Which indicates a high likelihood that he was not part of the main-net at that time and should have ceased processing Atoms.  

The fact that he didn't stop, also suggests a fault or dishonesty.

Bob has a few challenges to overcome here:

Challenge 1

Bob can never be sure that he controls a shard or a set of them.  He can't prevent anyone else from maintaining that shard, nor them being asked about Bob's transactions.  

Say Bob constructs an Atom(x) which Alice receives.  If there are any nodes that Bob doesn't control, they will also receive Atom(x), either from one of Bob's nodes, or from Alice's or someone else.  Bob can't prevent these nodes from receiving it, because he has got to broadcast it to Alice somehow.

Bob later presents Atom(x') which conflicts with Atom(x).  Bob can not be sure that nodes that aren't his don't have Atom(x).  If they do, when they receive Atom(x') from Carol, they can inform Carol that it is not legit..with proof of Bob's previous transaction.

Challenge 2

Bob will have to manipulate his commitments in order to fool Carol and anyone that may have Atom(x').  He would have to create Atom(x) to Alice first, somehow let Alice know about it without Atom(x) information leaking to the network.  Later present the Atom(x') to Carol, then submit Atom(x) and the commitment information for him to "prove" Alice was first....double spending x.

Alice might also be part of the ploy.

This is quite the challenge for a number of reasons:

If Bob places Atom(x) into a commitment and makes that commitment known, he is then very likely to be asked to verify that commitment at a future time by a node he doesn't control; Such as when connecting to it, submitting Atoms to it, or when part of a Temporal Proof Provisioning with it.

If Bob doesn't verify any commitments he has submitted when asked, then the node he is connected with will not accept anything from him, nor send anything to him until he does.

If Bob creates two commitments, one which he keeps to himself containing Atom(x) for later use and another without it which he presents to the network.  When he eventually presents the original, it will break his commitment sequence in the network.

Recall from the paper that a commitment references the previous one.

Say Bob creates C(2) which contains Atom(x) and keeps it to himself.  To preserve his commitment sequence, C(2) contains a reference to C(1).

Bob then creates Atom(x') that is sent to Carol.  He can't create C(3), because if he does, he has to reference C(2) which contains Atom(x).  To preserve his commitment sequence and for it to be accepted, C(3) also has to contain a reference to C(1).

Later when Bob presents C(2) to prove the existence of Atom(x) BEFORE Atom(x'), there will then be TWO commitments from Bob that reference C(1).

The only way for that to happen is if Bobs nodes are either faulty, or he has manipulated his commitments.  Nodes do not modify what they have unless there is verifiable proof that they should.  Bob can not have 2 commitments that reference C(1), therefore it can not be proven that Atom(x) was first.

After 5 long years of hard work, failed attempts and lessons learnt, we present the whitepaper explaining Tempo, our ledger and consensus tech that was published this week.

You can get it at our website https://radix.global

It details how our ledger architecture allows high throughput, rapid settlement and offers a true micro-payment and IoT solution, along with the consensus algorithm which we developed to secure it.

Tempo is a completely different way of thinking, and I would STRONGLY suggest you leave anything you know about blockchain, DAG, and other ledger tech at the door, otherwise you will end up with incorrect conclusions.

This paper is the first of a set that will explain all of the Radix core features such as economics, DEX, payment rails and more.

I'll keep this short and let the paper do the talking.

As always, comments, thoughts and feedback welcome.

You just explained exactly a Block-Tree which I developed back in 2012, which the original eMunie project used.

It doesn't provide an sufficient scalability improvement over a blockchain and was subsequently dumped in 2014.

The overhead required to maintain the global state so that everyone knows there are n number of child blocks to a parent block at scale becomes quite extreme.  This kills performance past that point.  

If you don't keep all nodes consistent to the very latest information (CAP theorem gets in the way a bit here) then two problems arise:

1) Nodes may also not know what the main branch is because they don't have all the state information and reference parents in weaker branches by mistake.  If that happens, your main branch becomes weaker, because hash power is inadvertently distributed across many branches and lots of miners don't get rewarded.

2) New blocks that are children of old parents will be created and won't be included in the uncle list of the next real block of that parent due to it being created already.  

Your diagram that you put together shows exactly this (by coincedence I assume):



Block(X) is not reference by other blocks, maybe it came in late.  There is also no guarantee if or when it will be referenced by any future blocks either and therefore poses a double spend security risk.

You also have the problem that a dishonest miner can throw in a block on a recent parent with more POW than the other blocks referencing that parent and those which come after it.  That then becomes the branch with the most work.  Therefore, any inputs in a block higher up, can be represented in a block as a child of that new block.  If the input that is seen first is considered the legit spend, and those after it are considered double spends, well.....double spends can happen.

They talk about account balances being verifiable without requiring the entire ledger...though they don't detail how anywhere.

I would assume that it's doing something like Open Transactions, where each transaction includes the previous balance and the amount.  From that you can determine the current balance, and therefore run heavy pruning.

Known about this before it hit the mainstream news, was waiting for it to show up here.

I was quite excited until I read "consortium of nodes"...then I put the paper down.

Consortiums, Validators, Masternodes....meh....all the same trick.  Reducing the decentralization and attack resistance to increase scalability.  It's also targeted more towards private networks rather than public, so no good for us here.

400k TPS however is quite impressive even for such a system.

We're filing some patents on the tech for defensive measures and so that we can build a business model around the tech in the private space.

It's taken much longer than anticipated however as we've had to fully educate the patent lawyers on the tech which is a journey unto itself.  Whilst that is underway I can't say anything revealing about the tech in a public environment before the filing date as it would enable public disclosure and the patents couldn't be filed.

The filing now has a hard deadline of 13th July...after which I can reveal all about the ledger / consensus tech we have developed.

It's frustrating I know, but if we want to continue developing the technology for use in the public space and enable a organization/foundation to have a long term revenue stream from the private sector it was necessary.

Radix is not early stage and there will be some news in July regarding its launch.

Yeah that 500,000 is a nice number to put on a graph and the website blurb based on how big we hope the network to be within about 12 months  In reality, the Radix tech scales linearly with network growth.  So of course, at launch with only a handful of nodes, 500,000 is not attainable...as the network grows the throughput capability increases without bound.  As a rule of thumb, every 10 nodes brings 1000 TPS, so with a network the size of Ethereum for example, throughput capability is in the millions.

I refuse to comment on EOS specifically, so let me just say this...

Parallel processing is indeed very difficult, and was one of the main scalability issues we've spent 4 years developing a solution for.  A block chain, of any form, can not do true parallel processing in a responsive and efficient manner...period.  

If it was possible with a vertical architecture such as a block chain, I'd argue we would have found a way to do so already.  Instead we realized quite early on that the solution was to ditch the block chain entirely and start fresh with a horizontal architecture designed for the job.

8.  Miners don't have anything to do with scalability...they just produce the blocks.  The problem is the architecture of a block chain.   Mainly the issue is that when blocks get past a certain size (say 1GB for arguments sake) it takes longer than 10 minutes for that block to make its way to all nodes in the network.  By then ANOTHER block is produced, which also takes longer than 10 mins, then another, then another.  All the nodes just end up collecting blocks and (potentially) reorganizing the chain. At this point it all grinds to an almost halt.

9.  Say the Bitcoin network is 10,000 nodes, and another Bitcoin network is 10,000 nodes but has 100 master nodes.   Its MUCH easier to keep 100 nodes in sync with each other than 10,000, so bigger blocks could be used for more TPS.  The problem is that its also easier to attack 100 nodes and take them offline, or for 100 node operators to collude to abuse the network than it is for 10,000.

10.  Having many networks / side chains can help, but this also brings some problems.   First of all, you only have X amount of hashing power (or stake, or whatever).  If you then have 100 side networks / chains, in most cases you have to share X.  Each network then has the security equivalent to X/100 and its much easier for an attack to take control of that particular side network / side chain.

Another issue is that if you want to transact outside of your side network / chain, it is a complicated and slow process, so the benefits are only really seen if you are transacting with someone in the same network / chain as you.

11.  Most of the 3.0 tech being developed is really early stage (other than my own project Radix).  Theory mainly and little code hence the 18 month window.  I'm not even sure if they are announced publicly yet, just discussions I've had with people at events and meetups with ideas.  I'll check with the developers before I name them.

1 = No.  Block chains can't scale enough, even with an "unlimited" block size they will still hit a limit.  Only solution to that limit then is semi / full centralization.
2 = There is no choice with block chains, they just can not scale enough.
3 = Yes, on both counts.
4 = DAGs are a better medium term solution, but these too will have their own set of different problems eventually.
5 = I don't know enough about IOTA specifically so I can't (and wouldn't like to) answer.
6 = If its block chain based and the project is claiming scalability in the 10,000+ then they are either a) lying  b) semi / fully centralized c) both
7 = Yes...There are a couple of technologies being developed but they aren't ready yet.  You should start to see these 3.0 platforms in 6-18 months

Indeed yes, pruning should be implemented where possible.  Just wanted to point out the difference as it can seem quite subtle.

Pruning != Scalability

Sure, you can chop a hole in the bottom of the bucket to dump some water, but it can still only fill up as fast as your tap.

Pruning allows you to manage the size of the block chain over time, not how many transactions it can process per second.