Visions of Aeternity

Long post warning

What is the vision of Aeternity?

As a coder looking into making apps with a provably secure backend infrastructure (aka “dapps”/“aepps”), and a fan of Erlang and functional programming, I have eagerly observed Aeternity’s progress. I have long looked forward to the day when the infrastructure, dev tools, and documentation become mature.

I speak only for myself, but I’m sure that there is a significant cohort of skilled engineers in a similar position. Erlang is not a popular language, and for good reason: for many years, it has been a “trade secret” in the distributed systems/big data/messaging/surveillance worlds.

It seems that with the release of Lima and FATE, and the Universe One conference, Aeternity is rapidly approaching maturity. And yet, I don’t find myself as excited as I expected to be.

As we all know, blockchain holds the promise of restructuring the internet, finance, government, and society. Yet, to date, the greatest impact of blockchain has been darknet markets.

As we all know, the primary obstacle to blockchain adoption is scalability. Ethereum, which promised to be “The World Computer”, was overloaded by CryptoKitties, a single game.

As we all know, most cryptocurrency transactions occur on the centralized databases of exchanges.

As we all know, even the most popular “decentralized” networks are not so decentralized when it comes to mining and core developers.

As we all know, Aeternity is even less decentralized than Bitcoin or Ethereum.

It seems as though decentralization and scalability are mutually exclusive. To date, there is no workable solution to the Scalability Trilemma, that one may pick 2 of

  1. Decentralization

  2. Scalability

  3. Security

Aeternity’s scaling is focused on state channels, and unfortunately, it does not solve this conundrum. As I understand things – correct me if I’m wrong – state channels require

  1. a node

  2. that’s online

  3. assets locked inside the state channel

Given the difficulty of installing a node (could your parents do it?), the resources required to have a server always online, and the limit that an off-chain transaction value cannot exceed the value of assets locked in the channel, state channels are not, on their own, the silver bullet for bringing millions of people into the blockchain.

Ethereum’s (initial) vision of being the World Computer, however flawed it is in reality, is a beautiful dream.

Until recently, I thought it was Aeternity’s vision too. I thought that the Aeternity team, composed of expert distributed systems architects and engineers, was on the path to achieving it. Then I read this thread:

It dawned on me that my vision of Aeternity is deeply in conflict with that of leading Aeternity team member, Emin. The conversation continues in this thread:

What is my vision of Aeternity? Or rather, what do I predict to be the purpose of the network that “wins” the Blockchain Battle Royale?

I believe that Distributed Ledger Technology, or Blockchains that run Smart Contracts, are the future of Cloud Computing. What is Cloud Computing? One could say that time-sharing a mainframe is Cloud Computing, or so is shared PHP hosting, and that is perhaps technically correct, but for discussion sake I propose to define Cloud Computing in the following generations:

  1. IaaS = Infrastructure-as-a-Service (e.g., Amazon EC2)

  2. PaaS = Platform-as-a-Service (Heroku)

  3. FaaS = Function-as-a-Service (Serverless)

  1. CaaS = Contract-as-a-Service (Blockchain/DLT)

As I see it, the purpose of the Cloud Computing movement is to improve economic efficiency by reducing the amount of capital required to build scalable businesses. Before the Cloud, a startup had to buy and physical servers and networking.

Amazon and other Cloud providers streamlined development and brought down costs, enabling the emergence of many other “Unicorn” businesses.

Platforms like Heroku and Firebase brought the bar even lower, by handling server configuration, letting developers focus on the user experience.

Serverless computing was the next step forward, further abstracting away notions of resource scaling and deployment.

Ultimately, at some point in the near future, it will take just 1-Click® to go from a code repository (e.g. GitHub) to production.

I believe this is the purpose of blockchain. Now, to any experienced engineer, that sounds ludicrous. What about testing? What about security? These are problems to be automated by systems engineers, compilers, and AI.

I believe the point of blockchain is to let anyone write a contract, perhaps based on a template, and offer it to the world.

Ethereum and the ICO movement, of which Aeternity is a part, is the successful proof of this concept. In 2017, anyone could write a whitepaper and raise $5-50 million by copying and pasting some Solidity.

Ethereum has long since given up on being the World Computer, and today is focused on “DeFi”, DAOs, and “Radical Markets”. In other words, the Ethereum community has given up on reinventing computing, and is settling for disrupting finance, work, and government. In other words, the Ethereum community has given up on solving the scalability trilemma.

They have many initiatives that will be marginal improvements, but the current Ethereum roadmap schedules Cross-Shard Transactions for Phase 4 of Eth 2.0, predicted release: 2021.

Perhaps the scalability trilemma is as intractable as the CAP Theorem.

Security is a necessity; otherwise, there is no purpose to all of this infrastructural overhead.

Scalability is inherently valuable; each additional user increases the value of a network superlinearly.

Decentralization sounds good. Decentralization makes me feel good. I like the idea of it; that I don’t have to trust the operator of the platform[0].

But if there is to be a sacrifice of one of these values, then Decentralization is surely the sacrifice. At least until the invention of “Eventual Decentralization”, a la Eventual Consistency[1].

Indeed, Decentralization is more of a conceptual value than it is actualized. Bitcoin mining and development are arguably centralized. Ethereum research and specifications are the product of the Ethereum Foundation. And when it comes to Aeternity, the centralization of development is significant.

In fact, as a work-in-progress, a degree of centralization is good. Quite good, really! Indeed, leadership is a prerequisite of success in innovation.

I believe that Aeternity should lean into its centralization. Take pride in the fact that Aeternity employs the world’s most experienced distributed systems engineers. As I see it, that is the justification behind the ICO. Experts don’t work for free!

Bitcoin, Ethereum, and other “decentralized” projects suffer heavily from

  1. high latency communication


  1. poorly motivated developers

Because Aeternity is somewhat centralized, it avoids these plagues!

One misconception that advocates of Decentralization hold is that Centralized entities are antagonistic towards users/consumers/society, while Decentralized organizations are aligned with the people. This is a conflation of organizational structure and the degree of customer orientation.

To understand customer-driven development, I highly recommend reading this free short ebook, HYPERGROWTH by David Cancel.

To summarize, Customer-Driven Development makes engineers communicate with end users, short-circuiting the product feedback-and-iteration loop, accelerating development.

This is the opposite of how blockchains are developed! Blockchains like Bitcoin and Ethereum have protocol architects who write papers that specify code to be implemented by infrastructure developers. Then, (generally) junior devs write documentation which is read by “blockchain developers” who write libraries which are consumed by application developers who make dapps.

Critically, the architects, core infrastructure and library developers couldn’t care less about the end user. They primarily want to get twitter followers and watch the token price increase.

Cancel’s approach is to force his developers to be responsive to consumers. In the context of a SaaS platform like HubSpot CRM, this worked well, but it may be too extreme for a blockchain; I’m not recommending that Robert Virding take user feedback directly…

But I reference Cancel because he has led some of the most efficient product development teams, and I believe that Aeternity has the potential to be the strongest blockchain development team. But it will take focus.

Aeternity’s strength is in protocol development. But when it comes to dev tools, onboarding, documentation, design, strategy, and especially marketing, there is much room for improvement. Marketing and strategy are weak enough that I worry about the long-term viability of Aeternity.

First, given the quality of the development team, and the thoughtfulness behind writing the chain in Erlang, implementing Bitcoin-NG, including state channels and oracles in protocol, writing a functional smart contract language, writing a VM from scratch, and more, one has to wonder why there is near-zero coverage of Aeternity in the Blockchain Media.

I think that members of the Aeternity community and leadership have expected that superior technology would draw attention. Unfortunately, that’s not how our world works.

Blockchain is a competition to reinvent the most valuable institutions in our world, and the incumbents are not playing fairly, nor do they intend to in the future. Instead, they are observing Aeternity while they ignore it.

Do the leaders of Aeternity want to be “in” the blockchain scene? You know the deal: a twitter celebrity, attending conferences like big shots, with a crowd of journalists surrounding them and looking for a sound-bite. Perhaps they want to be approached by major corporations to “integrate blockchain into the supply chain”.

I hope we all realize that the only reason big corps support Ethereum is that Ethereum is no threat to them. A scalable blockchain is the opposite of what Microsoft, Amazon, JPMorgan, PWC, etc., want.

If there is anything to take away from my essay, it’s this point about strategy:

The goal of Aeternity should be to cannibalize the Base Aepp.

The Base Aepp is important, as it is the default mobile wallet for Aeternity. But the Base Aepp wants to be more than a wallet. It wants to be a browser or App Store. A Super-app. The idea is that every Aeternity aepp would be accessible inside of the Base Aepp.

On its face, this sounds like a good thing for Aeternity. But it’s actually a major limitation. Let me explain why.

Aeternity is extremely strong at infrastructure development, and relatively weak at marketing. So, when a developer makes an app on Aeternity, they are benefiting from Aeternity’s strength (infrastructure), but they actually are not helped by Aeternity’s marketing. On the contrary, a developer of an app would be marketing Aeternity to their users!

Now, this may sound ideal from Aeternity’s perspective. But from my perspective as a developer, it’s a nightmare. I, as a developer, want to Own The User Experience. I want to design the app icon. I want to design the app interface. I want to design the user onboarding process. As a business owner, I need to own my own brand.

In Aggregation Theory, Ben Thompson of Stratechery writes about the impact of the Internet on businesses:

This has fundamentally changed the plane of competition: no longer do distributors compete based upon exclusive supplier relationships, with consumers/users an afterthought. Instead, suppliers can be commoditized leaving consumers/users as a first order priority. By extension, this means that the most important factor determining success is the user experience: the best distributors/aggregators/market-makers win by providing the best experience, which earns them the most consumers/users, which attracts the most suppliers, which enhances the user experience in a virtuous cycle.

To succeed on the Internet is to “own the user relationship”, to paraphrase Thompson in his follow-up piece, Defining Aggregators.

This is just as true for Aeternity as it is for an application developer. And it is why I encourage Aeternity to evolve away from being an application developer. Instead, Aeternity should aim to Own the Developer Experience. To be the best platform to develop smart contracts on. The platform that makes developers the most money, with the fewest headaches.

Aeternity has the opportunity to power thousands of applications. This is a part of the vision upon which we all agree. It is what motivated the design of the Base Aepp as a browser/App Store. However, the browser/App Store, or Superapp, is putting the chicken before the egg.

Everyone wants to build The Western WeChat. The one app that does chat and payments and games and the Sharing Economy and banking and more. The reason why is that the makers of the Superapp become Masters Of The Universe. Indeed, with WeChat, Tencent is in the middle of the Middle Kingdom. And naturally, the Chinese Communist party is in the middle of Tencent.

I don’t believe that Aeternity’s leaders actually want all that would come with running a Superapp. Indeed, it would involve extensive communications with and regulation by government, intimate connection to clandestine services from all major nations, and being the target of elite hackers.

And even if it’s what Aeternity leadership wants, it is not in alignment with the needs of developers. One big reason why Toshi, Coinbase’s attempt at a Superapp, is disappointing, is “Real Estate”.

Toshi is a portal to all the Ethereum dapps. That means that gambling dapps and monster collectible games and Decentralized Finance and potentially healthcare dapps are all in the same location. This serves no one but Coinbase.

The other reason why the Blockchain Superapp is doomed to failure is “Nativity”. Or, the lack of a native experience. Plain and simply, Apple doesn’t want anyone to run a popular App Store for iOS but them. Apple will not play fair. The App Store is a cash cow; they take a 30% tax on every transaction! This is billions of dollars, billions that will not be given up without a fight. Even Google, which is more lax about these things, won’t just give up their tax.

Speaking of tax, Aeternity Foundation receives 10.9% of block rewards. (For what it’s worth, I support this sustainability measure. More on it later.)

On the surface, a Superapp seems like a way to kickstart the network effect. The thought would be that the more apps that are accessible by the users of one app, the more likely those users are to try out one of the other apps. And the more likely users are to try out a new app, the more likely developers will be to make new apps. That sounds like a virtuous cycle.

If you think so, it’s because you made a valid induction, but it requires a base case. That is, the network effect must be seeded; the flywheel must be kick-started. It can only be seeded by a quality experience, in which value is delivered to end users. Something that matters to people who don’t necessarily know or care about Aeternity.

The Killer Aepp.

I believe that the primary goal of the Aeternity Foundation should be to provide the infrastructure for hit apps.

But I don’t believe that the Base Aepp is optimized for this function.

Rather, the development, documentation, and promotion of Swift and Java SDKs for native mobile app development, along with the inclusion of Encoding and Decoding of contract call data in the SDKs, will encourage developers/businesses who focus on UX and marketing to build on Aeternity.

Speaking for myself, I am only interested in building native apps in Swift for iOS. I know that may sound wrong to Open Source activists, but it’s just how I prefer to invest my time.

It’s not my nature to tell people what to do, especially when there is much work involved in doing it. Yet, I do so now because I believe it to be in the best interest of this community and the broader world that the best technology win the Blockchain Battle Royale.

I do believe that most blockchains will not survive. A blockchain needs

  1. protocol architects

  2. miners (or stakers)

  3. investors

  4. application developers, and

  5. users

to survive in the long term. Without one of these 5 stakeholder groups, the value of the network to the other 4 is diminished.

In the greater Blockchain Community, there is an abundance of miners, investors, and potential users, but scarcity among protocol architects and app devs. Protocol architects are leaders who create the base of the technology stack. As the supply of protocol architects increases, so will the number of different blockchains. But app developers must choose which platform to build on. So, the real Battle is for the hearts and minds of app developers.

Ethereum is clearly in the lead, in terms of number of developers. But the average Ethereum dev chose to work in Ethereum because it’s the most approachable for noobs.

Aeternity, with an ML-based smart contract language, cannot compete for bodies against the JS-like Solidity, or the entry-level marketing of Ethereum. Rather, Aeternity can hope to attract most of the best developers. “50% of the top 10%” has a nice ring to it.

With that in mind, it is still, I believe, inexcusable that Aeternity has an elitist attitude of “pro developers host their own dev tools”. The fact of the matter is that the documentation and tools around smart contract development are not mature. If Aeternity sees itself as akin to Bitcoin circa 2015, that’s fine. But if Aeternity is actually more like AWS Lambda, then it’s an EPIC FAIL for the browser-based dev tools to break.

As I believe blockchain to be the successor to Serverless computing, I take the latter interpretation, and I was sorely disappointed to see that “decentralization” was prioritized over developer adoption.

If you agree that the Blockchain Battle Royale will lead to concentration in which 90% of transactions occur on 2-10 different blockchains, and if you agree that users will use the hottest apps, which makes app developers the stakeholder group in highest demand, then you must agree that documentation, dev tools, and developer-directed marketing deserve a significantly higher investment than Aeternity is presently allocating to them.

Furthermore, I must express my ambivalence about Aeternity Ventures. While I support initiative to fund Killer Aepps, I worry that the projects that receive funding sort-of become employees of Aeternity, and thus subject to

  1. favoritism over ventures that Aeternity does not fund

  2. pressure to do things “the Aeternity way” against the interest of the project founders, users, and/or other investors, and

  3. deadweight loss because Aeternity may fund unprofitable ideas that seek to expand the promise of Aeternity

It is my view that Aeternity should be unbiased with respect to applications built with it, and rather than invest heavily in funding the Killer Aepp before it is built, make it simpler for people to build the Killer Aepp, and this includes people whose project gets rejected by Aeternity Ventures. Indeed, if a developer pitches Aeternity Ventures and gets rejected, they may choose to build the app on another blockchain, or not at all.

Finally, on the subject of strategy: In Defining Aggregators, Ben Thompson describes 3 levels of Aggregators, where Aggregators are Internet-enabled businesses that modularize their suppliers and integrate many different user experiences into a sustainable and valuable user relationship.

Level 1 Aggregators: Supply Acquisition

Level 1 Aggregators acquire their supply; their market power springs from their relationship with users, but is primarily manifested through superior buying power. That means these aggregators take longer to build and are more precarious in the short-term.

Netflix is a Level 1 Aggregator

Level 2 Aggregators: Supply Transaction Costs

Level 2 Aggregators do not own their supply; however, they do incur transaction costs in bringing suppliers onto their platform. That limits the growth rate of Level 2 aggregators absent the incursion of significant supplier acquisition costs.

Uber is a Level 2 Aggregator

Level 3 Aggregators: Zero Supply Costs

Level 3 Aggregators do not own their supply and incur no supplier acquisition costs (either in terms of attracting suppliers or on-boarding them).

App Stores are Level 3 Aggregators

Thompson also describes Super-Aggregators, of which the only Western examples are Google and Facebook (Baidu, Tencent, and ByteDance are as well):

What makes Facebook and Google unique is that not only do they have zero transaction costs when it comes to serving end users, they also have zero transaction costs when it comes to both suppliers and advertisers.

As I believe that blockchain will concentrate into 2-10 (and likely < 5) networks, I believe they will all be a kind of Super-Aggregator. However, unlike Web 2.0 businesses which have free transactions and are supported by advertisements, the blockchain Super-Aggregators will be the networks that extract the greatest number of transaction fees.

Users, app devs, investors, and miners are all “suppliers” (of data, content, value, and security) to a Blockchain Foundation, and all of them except miners pay transaction fees[2]!

Aeternity can be a Level 4 Aggregator: Negative Supply Transaction Costs

The BRI, which awards the Aeternity Foundation 10.9% of the block rewards, is, I believe, a good sustainability measure. But wouldn’t it be better to index on transaction fees? This would make the Foundation directly incentivized to increase the scale of the network!

Today, the ratio of block rewards to transaction fees approaches infinity, but that ought to change as Aeternity grows more popular. And with the advent of Native Tokens (NTs) and the possibility of paying Tx fees in NTs, I think it would be good for the community if the Foundation was compensated in alignment with the miners.

There are 4 sides to the market that is a Blockchain: Investors, Miners, Developers, and Users. But Aeternity, or any blockchain that wants to survive thru 2035, would be well advised to focus on “developers, developers, developers”[3].

I worry that if the needs of app developers are not what drives the next stage of Aeternity’s development, Aeternity will not make it thru the Blockchain Battle Royale.

If the attitude of the Foundation and leadership is that Aeternity is for “professionals who host their own tools”, and the script kiddies, front-end designers, and bootcamp coders can go elsewhere, then when a truly elite developer discovers Aeternity, why would they even bother with paying the miners, and the 11% BRI to the Foundation?

If someone is building a Hit App, and they know it (say, if they are porting an already popular game to the blockchain, and they have it running on their own local testnet), why don’t they just fork Aeternity’s code, and self-mine?

For an Open Source Blockchain, code is the asset, and the account balances on the chain are a liability.

The major token holders, the Foundation and founders, ICO participants, miners, and other long speculators, are all dependent on high quality aepps to increase their token price. The developers and users of high quality aepps are the customers, the ones who pay the miners and Foundation, and whose existence the speculators depend to turn a profit.

As a technologist, I hope that Aeternity becomes foundational to the next generation of Internet infrastructure. And to do so, I hope that the Base Aepp, peace be upon it, is outcompeted by the blooming of a thousand unique aepps, each with their own UX, UI, branding, marketing, and strategy.

I hope that Aeternity focuses on developers because I know that finance, government, and society cannot be restructured without reinventing computing.

[0] And while I like having the option to not trust the operators of the platforms I use, I like to trust people I do business with. It makes me feel good.

[1] I hope that as the Erlang node reaches maturity, the development of the Elixir node can be resumed, and in a “decentralized” fashion, outside of the umbrella of the Aeternity Foundation

[2] In order to extract the greatest number of transaction fees, it is important to facilitate the ability for developers to pay for their end users’ transactions. This needn’t be default, but as an option it opens up many more kinds of user experience, such as subscriptions or payment in fiat for blockchain transactions.

[3] Focus on Supply



Thank you for the essay. I found it educational and I appreciate the links to sources (for further learning).

Re: Base aepp:

There are a few aspects, which while possibly not terribly obvious, are quite important.

  1. The teams behind Base aepp, Waellet extension, and AirGap are the first developers who experience the aeternity dev tools (SDK, Nodes, Middleware, etc). In the process of building these wallets / aepps enablers (this is the other way to think about them) we discover what a blockchain SDK really needs to be like (vs basing this on theory or previous, partially relevant experience). aeternity has first class objects like the NS, Oracles, and more… By testing out the NS in the Base aepp, while relying on the Middleware, the nodes, the SDK, and more we have the chance to improve the dev tools… to the point where they are in great shape for future aepp developers. Similar points can be made about best practices around the Middleware, nodes hosting, and more tools which devs benefit from (but might not be sure exactly how to use based on the size, complexity, and particular details around the projects they are developing).

  2. There are quite a few blockchain specific technicalities if one thinks of the Base aepp, or the Waellet extension (or AirGap) as aepps enablers (apps that allow users to sign transactions and allow developers to write aepps without handling account management themselves). Working out these technical aspects (ex. accounts management in a standardized way, aepps metadata in a standardized way, etc) internally so that aepps devs could later benefit from meaningful, efficient, and effective aepps development practices is quite valuable before a ton of aepps developers have turned to aeternity (or blockchain in general). As such you can think of these wallets/projects as enablers. They might not be needed forever–hopefully they are one day made obsolete because every aepp dev knows the best way to handle accounts, sign transactions on ae blockchain, take advantage of an amazing sdk (that’s already in existence)–but until this bright future is reached they are quite valuable.

  3. In the process of developing the projects mentioned above a lot is learned about user behavior. In the blockchain space a lot is said about UX… but not much research/experience is shared. My personal opinion is also that the UX of most blockchain powered applications is inferior to non-blockchain powered ones. To evolve past this state we need to learn as much as we can about the psychology of users, improve the interfaces we re working on, and share the knowledge (for other aepp devs to benefit from). Additionally, the entire blockchain powered apps experience needs to be elevated… for people to begin preferring blockchain powered apps over services like PayPal, Venmo, etc.

  4. I invite you to think of the the projects mentioned above as more akin to blockchain oauth or brave browser than as WeChat. Basically think of them as enablers, at least for now… not as a mega app.

Thank you!


@chmod777 Thank you for expressing your thoughts in this detailed essay.

I agree with you 100% on most points. The Base aepp is an exception here.

I think what @stoyan_ae, in collaboration with the SDK and Middleware teams, have achieved with the Base aepp is noteworthy. The aepp already looks like a proper wallet/account manager and could be instrumental in the growth in the FIRST ecosystem on aeternity. There could be many ecosystems. An aepp doesn’t have to be available inside the Base aepp to be successful. It could very well use the Waellet or some other account-management aepp. So on this point, I agree with what Stoyan mentioned above. The Base aepp (and all other aepps that are being developed currently) help the dev tools to mature.

On the communications/marketing side of your essay - I tend to agree 100% (“marketing”, the forbidden word). I believe we don’t do nearly enough to:

  • Enable developers to have a great first experience with aeternity technology
  • Explain the [competitive] advantages of ae tech to developers
  • Differentiate ae tech from all other available technologies

We rely too much on devs finding out (organically) about aeternity, spending time to learn how to develop on it (despite the difficulties, imperfect documentation and outdated tutorials). And we don’t produce “easy to consume” content dedicated to devs.

As you have mentioned above - we don’t make it easy for newbies to get started and we do have an “elitist” approach to developed. I am not a developer, but I don’t think this is the best way to scale an ecosystem.

Simply put, I don’t think the current dev-acquisition strategy works as efficiently as it should be and I want to try and change that.

I fully understand your point here.

Here again, I agree. Communications/marketing has not received enough attention so far and if we want aeternity to succeed, this needs to change - ASAP.

Again, thank you for spending the time to share your opinion/vision. I personally enjoyed reading it!


Hi @chmod777,

I enjoyed reading your essay and I think it touches a few important points which can make or break any blockchain project. I support your vision of a diverse market of aepps where developers can differentiate their aepps from each other and provide users with a unique experience or experiment.

Regarding the following point.

I believe the first 2 points are very valid and something nobody is disputing. However, these requirements apply now because the one reference implementation of the node (in Erlang) is progressing pretty fast on many levels so nobody is trying to make the node more accessible.
Once the major features have been completed and the protocol is stable another stage of development will start where I see the opportunity to address these points.

Point 3 is something I consider a requirement to satsify point 3 of the Scalability Trilemma. The work on state channel networks as outlined in the Virtual State Channels Yellow Paper will already extend the uses of state channels which can also relax this requirement.

Lastly in regards to the discussion self-hosting vs. trusted services, this is again a periodic issue. Because things are moving fast it is still rather hard for interested developers not to mention users to go trustless. However, I expect this to change as the technical products mature and the focus switches from low-level features to black-box usability.