Shortly after we published the Burst Dymaxion and long before HF1, the first sketched roadmap indicated Burst tx capacity would rise from 1 tps to 4 tps, then to infinite tps. This led to the following comment from user @alpha1skywalker on Twitter

This comment is as accurate as it is funny. Moreover it suggests a certain skepticism be due, as normally these things do not happen “out of nowhere”. We agree: they don’t.

Generally the way to the stars is paved with hardship. Wen moon? If you are NASA, spend $200bn in today’s money you get to da moon in a decade. Also, armchairs are usually unable to escape Earth’s gravitational well. The end of 2018 nears and we know the first sketched roadmap was off in many ways. Some things were too optimistic (Dymaxion and PoC3 before end of 2018), some were too pessimistic (4 tps after HF1) and some were simply non-existent (Tethered Assets).

In short, the roadmap was naive. What we understood in the past year was that “scaling a coin” is much more than just give it higher tps. A decentral cryptocurrency with global aspirations has to scale along many more dimensions. The Dymaxion is more than just infinite tps off-chain and parts of it – such as improved mining security, dynamic fees and increased on-chain capacity – have been delivered. Could we have made colored tangles work before the end of 2018? Absolutely! Although it would have been like strapping a booster rocket on an old Toyota Corolla to make it go 300 mph – it’s not exactly sustainable.

The true challenge is not to have tens or hundreds of thousands of tps. Every modern high-frequency trading server achieves that. The task at hand is to get to this transaction capacity with 1, 10 or 500 million participating nodes. The challenge is to actually get that many nodes installed and running. This means they need to be ubiquitous: on computers with all sorts of operating systems, mobile phones, embedded systems. It also means installation has to be “idiot-proof”, simply because 500 million people do not need to know about Burst and software – they just need to use it and in order to do so, it has to be secure and “just work”. Finally, 500 million chatting nodes should not DDoS knock-out themselves – or the internet.

Easy2Burst

Heos, who took over maintenance of Qbundle from Quibus, started the easy2burst project, see https://github.com/HeosSacer/Easy2Burst, a Qbundle successor for Windows, macOS and Linux with a 1-click-to-setup philosophy, using electron with the newest web technologies. Things must get simpler, more reliable, more widely available. Easy2Burst will make the way to Burst easy.

As developers we do know all the intricate features and details required to make “just work” happen. When looking at them in their entirety, we saw it was necessary to take a few steps back and when doing so it became obvious: Retrofitting takes you only so far. If you want to cover entirely new ground, you have to start from scratch and think big.

Think big.

Aspera

We reveal to you: Aspera – the next-generation Burst wallet

So “This is the big news?” Yes. And before you rush off to sell the news, here are two facts why we think this is really big news:

  1. We have done this before with the explorer, the pool, mining and plotting software. In every single case this has opened a whole new parameter space in the given application domain. It was impossible to operate a Burst pool with 10000 miners before there was a goburstpool/Nogrod, it was impossible to mine on your mobile phone and be the fastest miner before Scavenger. For Engraver you are yet to discover the full extent of its new parameter space – as it’s not only its unparalleled speed.
  2. Only a few cryptocurrencies could afford to have multiple language implementations of their wallets/clients. Bitcoin, Ethereum, IOTA to give some examples. Jelurida made a new implementation based off our ancestor NXT, but also a new coin in the process. Probably more than 99% of cryptos today are simple copy&paste projects with no real development teams behind them and most certainly not enough development capacity to implement a new own wallet from scratch. From this moment on, Burst is officially in the exclusive club of the few big cryptos who do.

Or is it? Aspera is more than just a re-implementation of the BRS in the Go language. It is new technologies, new algorithms, new concepts and in some cases even new paradigms. In short, Aspera is the newest of the newest the entire crypto space has to offer. It is state-of-the-art 2018 and it remains Burst. So no, Burst isn’t exactly in that exclusive club – it’s destined to affirm the technological leadership, and this time we are determined also to sustain it.

No more being the first one to have smart contracts and not capitalize on it. No more being the first one with atomic cross-chain transactions and not capitalize on it. Features introduced on Aspera will be vivid and kicking.

Some may remember the picture when we compared the old Burst pre-HF1 with the new Burst after HF1:

It’s fitting, for the new/current Burst is able to carry 75 times as many passengers as the old one did. Now we tried hard to bring you an adequate picture of the current Aspera and we believe it’s this one:

Yes, it is under construction and clearly it’s a whole different kind of ship. It doesn’t require any Java-VM anymore, it doesn’t require you to think about the database. It also doesn’t require you to bootstrap anymore. Why should you bootstrap when it has proven to sync with partial validation at an average(!) rate of 8000 blocks a second on various test flights? During these “test flights” the lead back-end developers of Aspera, ac0v and bold, had to be careful not to crush the bunch of BRS peers feeding them. Eventually they had to throttle down some parameters also not to crush the local router.

Even more Speed

Some necessary computations appear all over the Burst ecosystem: e.g. the plotter has to compute a nonce when plotting, as has the pool to validate a deadline submitted by a miner, as has the wallet to validate a deadline in a block. Speed-junkie extraordinaire JohnnyFFM, well known for his optimizations in the Scavenger and Engraver software, is providing a “burstmath” library, which will be common to all PoCC projects utilizing – among other – fast SHABAL implementations including support for various architectures, SIMD intrinsics and GPU. Of course, Aspera is among the first adopters of this library.

UI

So Aspera is a completely new back-end technology. What about the front-end? The main work there is being done by blankey1337 and cgb and here’s their overview about what has been achieved:

“The wallet UI has been rebuilt from scratch, using Angular, TypeScript, and LokiJS. It sports a refreshed look and feel thanks to Angular Material, and it features important security improvements like PIN-based Account Management. By leveling up the technology stack, we are able to develop features faster and with confidence. Using a framework enables us to focus on building features, and makes it easy to onboard new developers. We are very happy with the new architecture, and enjoy working in the codebase. It’s so easy that we welcome developers of all experience levels to jump in and contribute!”

As pictures say more than a thousand words, have a look at these current screenshots of the new UI:

Availability & Future Development

The Aspera repository can be found at https://github.com/PoC-Consortium/Aspera. Please be aware that it is currently intended for evaluation and development purposes only. You can not operate a full-fledged Burst wallet with Aspera yet. Also, make sure you are aware of the restrictive license for the Aspera back-end which explicitly forbids to use the code on any other blockchain that is not Burst – see the wording in the license for a more thorough definition.

The PoC Consortium will concentrate its capacities on Aspera development. All new features, such as the Tethered Assets, the Dymaxion, PoC3 and others from possible future CIPs will be implemented in Aspera.

Compatibility with BRS

Aspera will be fully compatible with BRS either by design or by means of various compatibility layers. Aspera wallets will provide the regular HTTP and P2P API for backwards compatibility with both BRS wallets and user space applications relying on this API. umbrellacorp03 – maintainer of the definitive API reference on burstwiki – is working together with back-end development to provide a complete and validated formal definition of the API.

Of course the Aspera wallets will provide a native modern and efficient API of their own and using this for communication among each other and supporting user space applications, such as the PoCC pool software. This is when the real music kicks in, as this will sport ultra-efficient protobuf communication via gRPC.

Aspera will enter the Burst ecosystem slowly and incrementally. Lots of development, testing and security audits are still required before it can shoulder the main load of running the network.

What will become of BRS?

Until Aspera can take over the main load of running the network, BRS – our Burst Reference Software – will remain our most valuable asset and will get all maintenance, security fixes and improvements as usual. Brabantian will take over the leading role of coordinating and realization of all tasks regarding the further development of BRS. He worked hard, so soon a BRS 2.2.6 is to be released with a vastly improved inter-wallet communication. He will need new helping hands if BRS is to keep up with Aspera development. Should the day come when BRS will be unable to follow Aspera, we will have to say farewell to BRS.

Per Aspera ad astra.

Total
4
Shares

Subscribe

Subscribe now to our newsletter

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*