A short analysis of the last few episodes.
In episode 8, which took place in March, we reached a new milestone of 5,300 nodes running and a speed of 800 Tps. Although it was not much more than in the previous episode as we had some instabilities. Basically there were two bugs, one of them you can see in the green graph curve. This was fixed between the end of March and April; and the second bug was due to the RAM being too high, so we made some initial improvements, but as you can see it wasn’t completely fixed until the next episode in April, so in the end it was a bit unstable as well.
Episode 9, it doesn’t look like it on the graph but it was much more stable. One of the reasons was the improvements in the mechanism of the way transactions propagate through the network. Before, in previous episodes, transactions were sent to all connected peers, but now we only send the hash header for the transactions and then, in the case of a commit, we send the full transactions so it consumes much less bandwidth, and this bandwidth is one of the biggest problems on many nodes so it improved the stability a lot for many users. We saw that we reached 6,000 nodes and we were also able to improve the number of Tps to 1,000-1,200 for most of the month which is a new milestone but still with less bandwidth consumed. At the end of the episode, in April, we did some benchmarking and further improved the number of Tps to 2,000-2,300, but not all nodes survived even though the bandwidth usage and also the CPU usage improved, but only 3,000 nodes which is between 2/5th of the total survived the 2,000 Tps, so we have to thank all nodes, we will try again in the next episode.
For this last RAM problem, people with 8 or even 16 Gb RAM had problems. There were some memory leaks and we found it a few days ago, so from version 10.1 onwards it shouldn’t consume much more RAM, it should stay between 2 or 3 Gb RAM and towards the end of the month we will try to reach 3,000 T/s.
Massa Prototype.
We are going to run a demo that we used at the April events. The idea is that if you look at the actual -Smart Contracts (hereafter SC) on Ethereum, Solana or other blockchains, you have to call them to perform an action. This is done with bots or human interaction and causes some problems because, for example for landing protocols, you have to rely on bus networks, which can fail causing problems in the networks. We have added the possibility to have autonomous SCs. These are SCs that you can programme that will have automatic triggering capabilities so that they can perform an operation that you tell them to do: trigger in a couple of blocks or how to listen for events and perform operations based on those events. Another thing we added was the decentralised web. What we noticed was that SCs are said to be immutable but they are accessed through a standard website, which can be compromised, as has happened in the past, so we wanted to assign the same security guarantees to websites as to SCs. These decentralised websites are hosted entirely on the blockchain and you can access them through a browser plugin.
So if you access the Massa website through the plugin, you can watch this little game that is very popular among computer scientists. What I want to explain is that this game is running entirely on the blockchain, there is no centralised server, it is not a normal website but all the code is running on standalone SCs on the blockchain. Every 500 milliseconds there is an update that runs automatically on-chain, it’s a very simple demo and it’s interactive, so it responds to the actions we perform on the screen with the mouse. This is the first demo we show about autonomous SC with a decentralised website hosted on the blockchain.
The address of the game page is associated with the DNS in a SC, so the domain name resolution is in the string and then the browser will open it.
Questions from the community.
About the rewards, how will the allocation of score points in Massa tokens be?
We have had this question from the community before, we don’t currently know with your score how much you will be allocated as it depends on several factors. Mainly on how many people are participating and how many points these people got. We have a total of tokens allocated for testnet participation, so we can say it will be around 1% of the supply and towards the end of the testnet, a little before the mainnet we will see how many score points were rewarded and how many massa will be allocated to each point, and you will be able to claim them with a KYC. But more exact information about token allocation will be given in the white paper.
Are you planning to allocate reward tokens for other activities besides the testnet nodes, for example for finding bugs?
Yes, of course. One thing is participation in the testnet, but you can also get mass tokens through other means, such as the ambassador programme. Another way is the reward programme which will be launched soon and also the grant programme where you can apply for any proposal on how to build, we will review the applications and give the grants to those who decide. All the information for the grant programme will be ready probably this month, on our website we will have a page for this.
Is there an ambassador programme planned?
There is an ambassador programme as we discussed earlier, it will be based on the concept of core ambassadors and community ambassadors, we are in the process of finalising the design.
Will there be similar competitions and rewards?
There will be some reward tables related to content produced by the community, it is something we plan to do and we will launch it with the ambassador programme.
How is the DAO going to be organised, what will be the criteria for voting on a proposal?
This is something we have to look at in the long term. The issue is how we change the parameters of the network, how we change the ledger, how we decide for example to give more massa or increase the supply to finance anything. All this will go through the native Massa DAO, and the main idea is that you will be able to vote and the votes will be taken into account in proportion to the massa you have. The rolls will determine how much weight you have in the votes and you can vote to change things like block rewards, or to change an entry in the ledger, or if we want to block some people for bad behaviour. If the majority of Massa holders agree, we can cut back, we can fund, we can remove some data that is in the ledger that is not in line with the spirit of Massa, and so on. This is not easy to develop so it will probably come next year after the mainnet, but we still have to work on the details, on the specifics of how it will work.
Will you allow users from Russia and Ukraine to participate in the ICO?
The ICO is right now planned for a little bit before the end of this year, we will try to have as many people as we can and if there are any regulations or laws that make it impossible for us to have any country, any region, of course we will respect the laws, but we will do our best to have as many people as we can.
On the use cases that Massa would like to develop on the blockchain, any relevant sectors?
We have many ideas, one sector obviously is decentralised finance, where we have seen a lot of security flaws these years. One way to greatly reduce those attacks would be through a decentralised web and autonomous smart contracts, because it would add a great layer of security to these applications. And another sector that we are very excited about is gaming, we think autonomous SCs can be a lot of fun in the gaming industry. There are a lot of possibilities in developing games running on the blockchain, you can even imagine a bit of artificial intelligence programmed with autonomous SCs performing operations on a game running on the blockchain. You could have NFTs with a lot more user interaction, which would perform things autonomously. It has a lot of possibilities and it’s something we’re a bit focused on.
Which of the current blockchain problems can Massa solve?
We have observed three big problems in the blockchain space. The first is the lack of decentralisation, the second is scalability issues and the third of course is security. Therefore, our goal is to be as decentralised as possible, that’s why we have chosen the new architecture in Massa that allows people to participate easily with a normal computer. The barrier to entry is low and the current distribution is also very balanced to ensure that everyone can have tokens without dominating the network or breaking it. But we also add some innovations that go in the direction of decentralisation. One of them is the decentralised web and another one is the standalone SCs, as Adrian mentioned, which allows people to deploy DAPPS on Massa without having to deploy any kind of infrastructure most of the time, so most of the time you will be able to deploy your application on the website that comes with it, without any kind of centralised server requirements and that interferes with both security and decentralisation. In the case of scalability, we are trying to increase as much as we can the Tps that the network can handle. At the moment we are achieving 1,000 Tps but the goal is to increase with each episode. We have a lot of ideas on how to improve performance and we really hope to be able to reach the theoretical limit of 10,000 Tps. On the security side, when a network is not decentralised, its security is only as secure as the security of the infrastructure that supports it, so this is the first security milestone we will reach. The problem will be eliminated by decentralisation, of course, we will do some audits and we are currently building a security team that will work to ensure that the Massa blockchain is completely secure. We will also try to solve other issues related to the blockchain, such as usability, making sure that everyone can use it, generating documentation so that it can be easily developed on top of it.
As you indicated in the last AMA, you have been looking for an alternative and updated cryptographic primitives. Have you found it?
We have done the studies we announced in the previous AMA, all these discussions are public on GitHub. We have studied the different cryptographic schemes that are available and at this point we have almost decided to switch completely from SHA-256 to BLAKE3 as hash algorithm. This would have a big impact on the performance so it will improve the CPU performance by about 4 times. For the signature scheme we are going to change the SECP256K1 scheme to a slightly more complicated and richer scheme that implements some things like mobile synchronisation. These couple of changes are going to improve the performance of the network, the tricky thing is that we also need to update all the Massa tools to support these new schemes because the address format is going to change. We are still working on updating the whole Massa environment, but the code update is ready and we can merge it whenever we want. As far as we know, it will be the first blockchain to support BLAKE3.
On operation propagation, has the high bandwidth usage been solved?
We have worked hard to change the way transactions are propagated. Previously we announced the change in the full transaction to everyone around us. Each node would propagate the full transaction to all the nodes around it and that has changed, now each node will first announce the hash of the transaction it has and then other nodes can check if they already have that transaction or not. All this reduces the total number of transaction propagations. We see almost a factor of two in bandwidth usage and when we start using the heavier SC transactions, these transactions will be much larger.
One goal was to implement a javascript library that can be used in the browser to interact with the plugin. Has this been achieved?
Yes, we have implemented a web3 library and you can see it in the Massa Labs repository on GitHub. It is the first version and we have already used it in the hackathon. Basically we have this web3 that allows web developers to interact with the Massa blockchain in the same way as you see on other blockchains with the added extra of the standalone SC features and the possibility to host them on the blockchain. There are still some updates to be made to the documentation and performance, but the features are already there.
Have you managed to optimise the increased size of the ledger?
The question here is related to the way we bootstrap the network, so that every time a person boots up they need to download the entire ledger, as well as the last final blocks. This used to create several problems, first of all, the servers provided by Massa were quickly overloaded and some people in different parts of the world could not access them as easily as others due to internet connectivity problems and of course the way the download of the ledger was designed, we now send in one package the whole ledger. That creates big problems when the whole ledger grows, so we have done a lot of work on these aspects. It was also difficult to diagnose problems with the boot because the errors were not very explicit. Now we have four more boot servers and we have tried to distribute them geographically. There are two more in Poland and two more in Canada, and this will improve the boot experience. We have also worked to improve the bootstrap process itself to implement a full bootstrap where instead of getting a single package containing everything, it allows you to stream and resume broken bootstraps. This way the bootstrap process will be smoother and there will be much better diagnostics with much more detailed error descriptions, helping to diagnose bootstrap problems much better.
Is there a system to move from one version to another in a more decentralised way?
The question here is how we can do this in a different way, as right now we need to stop the whole system and start a new one because we don’t have a version control system that allows for smooth version transitions within the network while it is running. We have started a lot of groundwork on this but we don’t have anything to show in the current episode yet.
Are there any new warnings?
We have built in a lot of diagnostic logs on the nodes but we will possibly reduce this in the next episodes. We still need to diagnose a lot on our servers and you will see a lot of information logs on your node, there are also new diagnostic logs in the bootstrap.
Are we going to be EVM compatible?
Currently we have opted for a web assembly machine, not an EVM virtual machine, so this last step is to work on the web assembly machine, to make it usable. The EVM question is not totally closed because the goal is that once we have this web assembly machine we can continue to work on extending it. We could imagine creating a virtualisation layer that can help simulate EVM systems, or we could also add an EVM machine along with the web assembly machine, but for now we are mainly focusing on this web assembly machine and making it high performance.
Can you explain why roles are sometimes sold too often?
Basically every time your node does not produce blocks. When it is selected to produce blocks after a while and loses 70% of the production opportunities it had during the cycle, its roles will be sold automatically. This can happen for example if you had connectivity problems, performance problems or if you bought rolls but forgot to register your node with your private key. If there are a lot of people staking what you need to be aware of is that the chances of making blocks will get lower and lower. The problem with that is that if you have only one chance to make a block per cycle and you miss it then your roles will be sold.
About the hardware requirements
These haven’t changed (4 CPUs and 8 GB RAM), but at some point in the next few months, we will ask that you have a bit more like the final requirements that we want for the network, which is still something that many people will be able to have on their standard computer, 8 cores and 16 Gb RAM, and with this you will be set up for 4 years.
Last words from the founders
We are growing in the network, in number of nodes and the amount of features we are implementing. We are slowly ticking each of the boxes on the technical roadmap, but we are working on many things in parallel. We are still hiring and everything is running smoothly on our side, and we also think we have one of the best communities in the crypto space and we want to thank you again for that.
You can watch the full AMA at the following link: https://www.youtube.com/watch?v=RpaM4uxh3Mg
Follow us on
