AMA Session 07/11/2023
Table of contents
- Engagement and transparency are key to building a thriving community—let's connect every two weeks to keep the conversation going and stay updated together.
- Scalability is the key to maintaining decentralization while ensuring network security and optimal transaction costs.
- The future of decentralized systems hinges on solving scaling challenges through innovative algorithms and smart contract solutions.
- Innovation in decentralized systems is key to unlocking the future of blockchain technology.
- Collaboration between research and development is the key to driving innovation in technology.
- Innovation in blockchain is about predicting the future and adapting to it, not just following trends.
- Innovation in blockchain is all about balancing scalability and decentralization—it's a tradeoff that can define the future of technology.
- Waterfall is redefining the scalability-decentralization tradeoff, aiming for high scalability without sacrificing decentralization, all while stepping beyond traditional blockchain limitations.
- Stay flexible and adapt your roadmap; innovation thrives on change.
- Decentralization is the future, and we're building a community-driven protocol to make it happen.
- Building your own version of Uniswap is easier than you think—open source code makes it possible!
Engagement and transparency are key to building a thriving community—let's connect every two weeks to keep the conversation going and stay updated together.
Hello everyone! We are very happy to welcome you here today. This is our first AMA session, which marks a significant milestone for our protocol, community, and collaborative efforts with multiple organizations. We will do our best to address all the questions you have asked. However, in case we miss something, we will ensure to address those questions in two weeks, as we are planning to hold AMA sessions every two weeks. This will allow you to receive fresh and updated information regarding the status of our work, who is joining the project, and various technical, business development, and other updates that we are implementing or have already implemented at the time of the session.
With that being said, I would like to pass it to my colleagues to start with a series of introductions. This will be the first part of the AMA session. Please go ahead!
My name is Islan Sh. I obtained a master’s degree in mathematics from Messa National University in 2015, and I defended my PhD thesis in the field of mathematical analysis. My dissertation was devoted to the study of certain classes of functions that arise in harmonic analysis. Currently, I am an associate professor at the Odessa National University. In recent years, I have been working in the field of distributed technologies, specifically distributed ledgers and blockchain technologies. In the Waterfall project, I worked on the development of consensus light workers, light nodes, and Shing nodes.
I would now like to share a few words about how consensus works in the Waterfall. First of all, the Waterfall Network is divided into two parts: the coordination network and the BL dock network, or Shar network. The operation of the Waterfall network is divided into rounds called slots, with a box consisting of 32 slots. The BL dock network is designed for randomly selected nodes to publish blocks containing transactions. Unlike traditional blockchain systems, in one round, more than one block can be published, and these blocks can reference more than one block from previous slots in the block dock network. Thus, the BL dock network forms a directed acyclic graph structure with slots.
The detailed functions of the block dock network are presented on this slide. The coordination network is designed to determine the order of execution of blocks in the block dock network. The consensus in the coordination network is based on proof of stake, which introduces finality into the network—a state that cannot be reversed. Additionally, optimistic finality is introduced. More detailed functions of the coordination network are also presented on this slide.
In general terms, the Waterfall network is divided into two networks: one network is responsible for the propagation, publication, and execution of transactions, while the other network focuses on achieving consensus regarding the ordering in the block dock network. Finally, the Waterfall network has the properties presented on this slide.
In conclusion, I would like to note that the use of a block dock structure in the Shar network enables parallel execution in the network operation. By utilizing this structure, we achieve scalability and decentralization across every shard of the network. Using dock and the coordination network, we aim to achieve a virtually unlimited amount of shards, which can lead us to virtually unlimited scalability. This approach allows us to preserve the decentralization of the entire system and each of the subsystems it consists of. Thank you for your attention.
Hello, it's good to see you all here! My name is Yan Leon, and I am an associate professor with a PhD in mathematics at the Odessa National University in Ukraine, where I have worked since 2002. My research expertise lies in the mathematical modeling of complex systems, such as computer, environmental, and economic systems. In recent years, I have focused on the field of distributed ledger technology and have been involved in numerous projects related to decentralized public and private networks. Over the last few years, I have actively participated in such projects and gained expertise in...
Scalability is the key to maintaining decentralization while ensuring network security and optimal transaction costs.
Scalability allows us to preserve the decentralization of the entire system and each of the subsystems it consists of. Thank you for your attention. Hello, it's good to see you all here. My name is Yan Leon, and I am an Anastas Professor with a PhD in mathematics at the Desa National University in Ukraine, where I have worked since 2002. My research expertise lies in the mathematical modeling of complex systems, such as computer, environmental, and economic systems.
In recent years, I have focused on the field of distributed ledger technology and have been involved in numerous projects related to decentralized public and private networks. Over the last years, I have actively participated in such projects and gained expertise in this field. My contributions have been in the system design and the development of economic models. I am excited about this project's potential to make a positive impact in the mass adoption of decentralized finance and believe that my skills and expertise can contribute to its success.
Now, I will share my screen for a moment. Today, I would like to give you a brief overview of Waterfall Economics. It has a few special goals, which you can see in our economics paper on my screen. Just a moment while I adjust this.
These pictures show the high-level economics design and coin flows. Our main aim is to create a favorable environment for incentivizing the positive behavior of each network participant and the system as a whole, as well as for providing an optimal data replication rate ratio and affordable transaction fees. Block production is incentivized with minted rewards for each finalized block of the coordinated network.
This figure presents the analyzed return rate that could be generated by stakeholders as block rewards at various total stake amounts. At the initial stage, when there is a small number of workers, a significant annualized return rate can be assumed. At the start, the return rate is expected to be higher than 700%. However, as the number of workers increases, the return rate decreases sharply. For instance, with a stake of 1.5 billion, the expected return rate drops to 50%, and it reaches a value of 20% with about 10 billion water staked. Therefore, a balance between the volume of minted coins and network security is ensured.
Regarding the base transaction fees, a base transaction fee must be paid for any transaction included in the block. Its value depends on the total number of workers in the system. For example, when about 3 billion coins are staked in the system, the base transaction fee is just about 0.01 water. However, with a total stake of around 12 billion coins, the fee increases almost twice. A significantly large number of workers results in greater network reliability and security of the platform. The general rule is that an increase in validators of a shard gives higher transaction fees, but transaction fees become lower with an increase in their number and in the number of shards.
There are many points to be discussed in detail, particularly coin burning and the inflation-deflation process. It's worth noting that all the results obtained from simulations in the Waterfall test net were fully in line with the theoretical calculations made by the formulas. Our economics model is presented in four papers published in scientific journals. Let’s open the last of them for review.
Just a moment while I pull that up. You can see this paper on my screen; it is fully open for reading. A lot of our researchers work on this model, and I hope that one of our future meetings will be dedicated solely to economics, allowing us more time to scrutinize this issue.
Thank you all for your attention, and I look forward to discussing this project further with all of you. Thank you again for the great presentation.
Now, let's continue. Does anyone from the audience have questions?
Thank you, I pass the floor to Eager. Will it be you?
Okay, can I share my background video?
Yes, you can share the screen.
Alright, good day everyone. I am Dr. Iger Murok, an Associate Professor at the Faculty of Mathematics.
The future of decentralized systems hinges on solving scaling challenges through innovative algorithms and smart contract solutions.
I hope that one of our future meetings will be dedicated only to economics, allowing us more time for scrutinizing this issue. Thank you all for your attention, and I look forward to discussing this project further with all of you. Thank you again for the great presentation.
Let's continue. Does anyone from the audience have questions?
I pass the floor to Eager.
Yes, can I share my background video? Yes, you can share the screen.
Good day, everyone. I am Dr. Iger Murok, an Associate Professor at the Faculty of Mathematics, Physics, and Information Technology of Odessa National University. I work in the Department of Optimal Control and Economic Cybernetics, and I am also the head of the Educational and Research Center for Algorithms and Programming. I hold a master's degree in Applied Mathematics and a PhD in Computer Science.
For a long time, I have been involved in developing computer-aided topology design systems for complex technical systems and knowledge-based distributed information systems. For the past eight years, I have been designing public distributed ledger systems based on blockchain and directed graphs as the head of the Research and Development Laboratory. During this time, I have participated in several successful projects.
In addition to my R&D activities, I teach courses related to developing algorithms and software for distributed and decentralized systems. I also coach my university students to participate in sports programming competitions. My team has successfully made it to the finals of the World Championship in programming, the International Collegiate Programming Contest (ICPC), several times.
I am on the Committee for Distributed Ledger Standards and am a member of the Editorial Board of several scientific journals. About two years ago, along with my colleague Eugen, whom we already met before, I joined the development of the design and economics of the Exciting Waterfall Project. Currently, I am mainly concerned with scaling the system at various levels using partitioning and sharding techniques. We are developing Waterfall as a public decentralized system with smart contracts.
To achieve efficient operation with a very large number of fast transactions and a large number of nodes, we face several scaling problems: large and rapidly growing ledger size, large network traffic during ledger synchronization, large traffic when performing transaction pool synchronization, large computational costs for the execution of smart contracts by all nodes, and a large amount of memory required for permanent storage of smart contracts data.
My colleagues have already discussed some solutions to these problems, and I will talk in more detail about my focus. I am primarily focused on solving ledger and smart contract problems. To address the issues of scaling, storage, and synchronizing the ledger, we have developed several solutions, including specific sharding techniques. All sharding solutions are united by one common technical coin, which allows us to minimize inter-shard transactions and solve many related problems.
For the problem of unlimited ledger scaling and smart contract execution, I have a promising idea based on the CAD algorithm, which I hope will allow for unlimited regulation of the replication coefficient. The common use of this approach, in my opinion, can open up interesting prospects for high-level applications such as payment systems, web3 gaming, and others.
Thank you, Eager, for this insightful presentation. Just to clarify for the audience, Roslan, Eager, and Yan are currently focused on addressing the update of the coordinating network and the proper implementation of sharding. For this task of virtually unlimited sharding to be solved in the right and most efficient way, there are many underlying tasks, including synchronization, etc.
As part of this AMA session, we will not go through all the details, but later there will be more focused AMA sessions on particular angles of this topic. This will allow us to delve deeper and explain what we are doing in each of these directions, including sub-directions.
Innovation in decentralized systems is key to unlocking the future of blockchain technology.
Insightful presentation! Yes, definitely. Just to clarify for the audience, Roslan, Eager, and Yan are currently focused on addressing the update of the coordinating network and the proper implementation of Shing. For this task of virtually unlimited Shing to be solved in the right and most efficient way, there are many underlying tasks, including charging cination, etc.
As part of this AMA session, we will not go through all the details, but later there will be more focused AMA sessions on particular angles of this. This will allow us to go deeper and explain what we are doing in every direction, including sub-directions of this. Thank you so much, Eager. Does anyone have any questions for Eager?
Oh, maybe next in my section? Yes, I think you should collect questions and prepare answers. Then, probably most of the questions will be written in a couple of days when people review the recording. Thank you so much, Eager.
Okay, so who is next? May I? Yes, Al, is it your turn?
Yes, thanks for giving me the floor. Hello, nice to meet you all! I am Alisa V, and I work in the research team. I am from Odessa but now live in Lille, Italy. I have a master's degree in Applied Mathematics from Odessa National University, where I also graduated with my bachelor's degree in the same field. Additionally, I hold a master's degree in mathematical engineering from the University of Lille.
In my master qualification project, I explored centralized systems modeling. My colleague and former supervisor, Eager, has already shown an example of my simulations in my projects. For my master qualification project, I focused on the topic of simulation modeling and optimization of hierarchical consensus in permissioned blockchains. Later, an article expanding on this topic was published. This study aims to improve the performance and efficiency of the consensus algorithm by addressing several challenges. The results of the work were obtained using methods of mathematical and statistical analysis and after conducting a series of simulation experiments.
On the screen, you can see the proposed algorithm of partitioning coordinators to minimize the number of M slots and some of the simulation results. If you are interested in the details, you can refer to the article that is on the screen. In general, my attention has been directed toward Blockchain and DLT for one and a half years. I have actively participated in different decentralized platform projects. My main research interests include decentralized systems, distributed ledger technology, simulation modeling, and data science.
My core role in this project, as you could have understood, is systems modeling. One of the last publications that I have, together with my colleagues, is dynamic bandwidth adjusting in block deck networks. This paper presents a flexible approach for dynamically adapting a decentralized network to fluctuations in the transaction flow. This adaptability is crucial for public platforms, as they must be able to evolve effectively under varying workloads. Here are the formulas that are proposed in our case, and these are the results obtained from the simulations. You can follow the link to the full text.
That is all I wanted to say. Thank you for your attention, and if you don't have any questions, I will pass the time to the next speaker.
Yes, sure, sounds good. Very insightful! Does anyone have any questions? Assuming we don't have a large audience online, most probably the questions will arise after the recording. So maybe we will need to go to another speaker.
Hello, dear community! I am Danis G, and I work in the second R&D team. The team lead of this team is Ran Shining. I live in Essa and have a bachelor's degree in program engineering and a degree in supercomputer systems and networks. I also have a master's degree in computer engineering and am currently pursuing a PhD in computer science. My research interests are cryptography, cybersecurity, and decentralized systems.
Collaboration between research and development is the key to driving innovation in technology.
Basically, yeah, that's a good start. So, does anyone have any questions? Assuming we don't have a large audience online, the most probably will be happening after the recording. So maybe we will need to go to another speaker.
Hello dear Community, I am Danis G, and I work in the second R&D team. The team lead of this team is Ran Shining. I live in Inessa and have a bachelor's degree in program engineering and a degree in supercomputer systems and networks. I also have a master's degree in computer engineering. Currently, I am getting a PhD in computer science. My research interests include cryptography, cybersecurity, and decentralized systems.
My previously validated projects include an encryption model of small text messages and a decentralized system of control for gas stations. My core role in these projects is programming and modeling systems. Currently, I am working on a new consensus modeling system. The last published results involve modeling subnet dividing results.
Now I want to show my screen. One second... I see my screen, yeah? Yes, we can see you. Just a reminder, the base DS of subnetworks concept is to increase the TPS rate and parallelize the transaction pool.
Now you can see the table of some results of modeling. These are the tested algorithms, their names, parameters, criteria, and results. The colors mark the better algorithms. Now, you can see the modeling graphics results. On this page, you can see two algorithms; one is not good, another is 50/50, and one is good.
Now you can see a mapping graphic of modeling results. On this slide, you can see a comparative diagram of results between algorithms. The colors mark the criteria of results. So that's all. Thank you for your attention, and let's go to the next speaker.
Thank you so much, Denise. So, are there any questions for Denise? No questions? So, who is next? Maybe I... yeah, one moment.
Hi, my name is Alexander Nan. I am from Odessa, but now I am living in the Czech Republic. I got a master's degree from Odessa Polytechnic University in 2009. I started working as a developer while studying at university, and I already have 15 years of experience. I have been working with blockchain since 2008, and I have five years of experience where I developed various projects, including different hard wallets, smart contracts, and merchant projects with post terminals.
I have been involved in waterfall projects from the beginning. I am the team lead of the developer team, and I serve as a bridge between the research and development teams. That's all I will share for now; I will tell you about the status of the project later. I think you will have questions after my next presentation.
I want to describe about... maybe Vladimir will be next.
My name is Vladimir M. I live in Odessa, Ukraine. In 2011, I finished the Odessa Academy with a degree in software development. In the same year, I started my career, with my main specialization being web development on Node.js, but I also have experience with PHP, C++, and React.
Starting from 2019, I have participated in some projects related to blockchain. The applications were intended to provide interfaces to interact with Ethereum, such as wallet management, sending transactions, calling contract methods, collecting statistics, etc.
On the waterfall project, I have worked on the development of easy token for over two years. This involved directed acyclic graph data exchange between coordinator shards, data propagation, network synchronization of nodes, and data validation functionality.
Currently, I am working on the implementation of delegate functionality, which allows for setting flexible rules with valid data operations and defining the sharing of rewards and stake amounts.
Innovation in blockchain is about predicting the future and adapting to it, not just following trends.
To provide interfaces to interact with Ethereum, such as wallet management, sending transactions, calling contract methods, and collecting statistics, I have been involved in the development of the Waterfall project for more than two years. My work has focused on the development of easy token, directed acyclic graph (DAG) data exchange between coordinator and shard nodes, as well as data propagation and network synchronization of nodes. Additionally, I have worked on data validation, ensuring valid data functionality and operations such as deposit, withdrawal, and exit. My responsibilities also include overseeing the consensus of the coordinator and finalization processes.
Currently, I am implementing delegate functionality, which allows for the establishment of flexible rules regarding valid data operations and defines the sharing of rewards and stake amounts for participants.
At this point, I apologize for being muted. Would you like to share something about your current work? Perhaps you could provide an overview of the cases you are working on, or specific parts you are focusing on. It might also be helpful to walk us through the GitHub repository we have, which is still not public. However, some people are already reviewing it and have confirmed their support, indicating they plan to utilize it. If you have something to share, let’s do it now; if not, we can discuss it later, perhaps after the launch.
If this introduction session is concluded, I would like to take the opportunity to introduce myself and share details about how Waterfall was born, how we all met, and how we work together.
My background includes over 15 years in software development. I previously ran a company focused on software development and digital marketing services, which is still active, although I am no longer part of it. During my tenure, we received several awards and achieved a successful exit through the acquisition of a fintech startup by one of the top banks in the United States. They were primarily interested in our technology rather than the business model, ultimately recreating and integrating our work into their flagship product.
My blockchain journey began in early 2017, during which I worked on Ethereum-inspired projects. One of my initial projects involved developing one of the first layer two solutions for Ethereum based on plasma, which attracted significant interest. At that time, our GitHub repository for plasma cash was one of the first working prototypes available.
In early 2018, we were working on an enterprise-grade sidechain and released our paper outlining our approach. Interestingly, a similar approach was later introduced by Erin Young at the end of 2018 with their project called Nightfall, which subsequently scaled and evolved into what is now known as the Basine protocol. While I do not intend to accuse anyone, I noticed similarities between what was presented in our paper and what they showcased in their seminars.
In conclusion, we were somewhat successful in predicting the direction of the industry, particularly concerning this specific design pattern.
Innovation in blockchain is all about balancing scalability and decentralization—it's a tradeoff that can define the future of technology.
The project was initially called Nightfall, and after releasing their first testing, they began to scale. It is important to note that this is not meant as an accusation; however, I was following their presentations and noticed similarities between what they were presenting to their clients and what was written in our paper from back in the day. Eventually, Nightfall was renamed to Basine Protocol, and other participants joined the project. With that being said, we were somewhat successful in predicting where the industry would go.
Speaking of this particular design pattern, we arrived at the conclusion that it is not a straightforward 0 to 1 transition, as described in Peter Thiel's book. There were limitations to the approach we selected, prompting us to move forward. I started my PhD focusing on the scalability of existing solutions, particularly with an emphasis on Ethereum. I was convinced that Ethereum, or at least the Ethereum Virtual Machine (EVM), would become the established standard. To date, the EVM has indeed established standards for smart contracts. If you look at the statistics regarding the number of decentralized applications (dApps) working with EVM, you will find confirming facts.
During my PhD, I became particularly interested in the topic of directed acyclic graphs. My team and I studied all the relevant concepts we were aware of, which eventually led to the birth of Waterfall. I came up with the initial concept, and then Alexander and Roslan joined the team. Alexander and I had been collaborating on various projects since 2016, including those focused on distributed ledger technologies. Roslan joined us in early 2020. Together, Alexander, Roslan, and I formulated the initial view and roadmap for the first test net of Waterfall, which was released in October 2021 in Dubai. You can find references to this in our Telegram channel. There are some interesting stories related to this that I will share at the end of this event if time permits.
Later, we were excited to expand our research group, welcoming Eager and Yan, who brought broader experience in organizing research groups. At that time, we created two research groups, and Alisa and Denise joined us, contributing tremendously to our modeling efforts. They have not yet fully presented their work due to time limitations, but this is only our first session. The main goal is to introduce ourselves so that you know who we are. Moving forward, we will highlight our work from different angles.
Recently, another researcher, Alexander Antonenko, joined us but is currently on leave to focus on his academic career. We hope he may return to us at a later stage, as we were happy to have him on the team.
In summary, the question arises: why Waterfall, and what makes it interesting? One key point is the common tradeoff between scalability and decentralization, which Vitalik Buterin highlighted in his article "Endgame." He is undoubtedly one of the smartest and most decorated individuals in the industry, having created the largest and most widely adopted smart contract platform. However, if we review the number of validators in the top protocols currently available, we can see the implications of this tradeoff.
Waterfall is redefining the scalability-decentralization tradeoff, aiming for high scalability without sacrificing decentralization, all while stepping beyond traditional blockchain limitations.
The discussion began with a note about a colleague who is currently focused on his academic career, with the hope that he may join the team at a later stage. The speaker expressed their happiness to have him with them.
Long story short, the focus shifted to the topic of waterfall and what makes it interesting. One of the key points raised was the common tradeoff between scalability and decentralization, which was highlighted by Vitalik Buterin in his article "Endgame." The speaker acknowledged Buterin as one of the smartest and most decorated individuals in the industry, noting his role in creating the largest and most widely adopted smart contract platform.
Upon reviewing the number of validators in the top protocols currently on the market, excluding Ethereum, it was observed that the numbers are not very high. Sometimes there are hundreds, and at other times, thousands, but it is rare for the number to surpass 10,000 validators. Ethereum itself is an interesting case, boasting around 800,000 validators, which is commendable, but it faces issues with transaction fees and scalability. This situation inspired the creation of waterfall.
The speaker chose not to delve into complex terminology such as Directed Acyclic Graph (DAG) or zero-knowledge proofs (ZK-SNARKs, ZK-STARKs), although these concepts are present in their papers. At a high level, they emphasized that the potential scalability of waterfall could be very high. While it is not unlimited, it can reach virtually unlimited numbers, with some inherent limitations.
With that being said, waterfall boasts a high level of scalability comparable to the most scalable protocols currently on the market. Additionally, by design, it maintains a very high level of decentralization. The speaker noted that while Ethereum is currently the most decentralized protocol, their consensus mechanism is designed to accommodate even more validators, referred to as workers in their context. The implementation of light nodes may further enhance this capacity.
The speaker acknowledged that there are substantial differences between their light nodes and those of Ethereum, indicating that this topic would be covered in future Q&A sessions. They reiterated that waterfall could be both highly scalable and decentralized, thus avoiding the tradeoff typically seen between these two aspects. They clarified that, importantly, waterfall is not a blockchain anymore, which is a key reason for this possibility.
Looking ahead, the speaker mentioned that they are planning to launch in the first quarter of 2024. They expressed enthusiasm about discussing waterfall and its features, which are fundamentally based on their PhD research, which they are in the process of defending. Currently, they hold the status of a PhD candidate.
The speaker then passed the discussion to Alexander, who would provide updates on the current status of waterfall, the team's direction, and short-term plans regarding their roadmap, which is available on their website. They noted that while the roadmap is subject to change, it reflects their current vision and priorities.
Finally, Alexander confirmed that he could share his screen, indicating readiness to discuss the launch of their first test network, which took place in October.
Stay flexible and adapt your roadmap; innovation thrives on change.
By the way, the information is present on our website, so you can always return to it and get familiar with what it is we're planning. It doesn't mean that we will never change our roadmap because it can happen; you know, we can prioritize some things over others and maybe postpone some other things or even insert some particular, maybe use case-oriented or infrastructure-oriented updates. But so far, this is how we see it. Currently, I'm passing the word to Alexander, so he will be able to share where we are and where we are going to go.
Are you able to see my screen? Yes, I can see it, and I assume others are also able to see it.
As mentioned, we launched our first test network in October two years ago. This test network still works, and we have about 16 million blocks for these two years. In August, we launched Snet 7, which is our last stability network. However, soon we will launch Snet 8, which will be the last test net before the main net.
Our first test network was running in October two years ago, as Sergey said before. Now, we have a prototype test network with about 16 million blocks. Two months ago, we launched some test networks and tested some functions, but we had to stop a test network because it spends a lot of money if we continue to launch all networks. Two years ago, we launched Snet 7 on 64 nodes, and it still works, with about 7 million blocks here.
Additionally, we launched a second site for workers where you can get information about how workers operate. We have main information about the count of workers, current slots, and which stakes are here, as well as how we get rewards over time. You can also see the maximum and minimum rewards that workers receive per epoch.
When we started the network, we had 248 workers, and now we have 250 workers. You can see how the balance changes and how rewards and penalties are distributed among all workers per epoch. Furthermore, you can see how rewards are distributed per one epoch and the overall balance for workers over time or for the last epoch.
Can I please return to this page? I would like to provide some more clarification on this topic. On the top of this page, a little bit down, yes. Basically, these rewards per year, rewards per day, and rewards per epoch are not fixed rewards. The consensus is designed to have hundreds of thousands or even millions of validators, and with the light nodes, it may go even further.
This is how it generally works with proof of stake consensus algorithms, and Ethereum is not an exclusion. The fewer validators you have, the higher the rewards, and the more validators you have, the lower the rewards become. For example, if somebody joins right now and becomes a validator, their rewards per day, rewards per epoch, and as a result, rewards per year will be reduced as well.
Please scroll down a little bit. As well as these numbers, which are essentially the same in absolute terms. There are advantages for joining the protocol earlier, and this is designed to achieve a very high level of decentralization. Currently, 248 workers are controlled by us, but we would like it to be controlled by the community. This is how it is designed because there are different levels of incentives for new members to join and for it to become a very decentralized protocol. More information can be found in the papers written by the group of Y and eager.
Sorry for the interruption, Alex. Please continue. Yes, we launched a test net with about 200 workers, and we have this...
Decentralization is the future, and we're building a community-driven protocol to make it happen.
The design of our protocol aims to achieve a very high level of decentralization. Currently, 248 workers are controlled by us, but our goal is for this to be controlled by the community. This design incorporates different levels of incentives for new members to join, facilitating the transition to a very decentralized protocol. More detailed information can be found in the papers written by the group of Y and Eager.
We launched a testnet with about 200 workers and have established a value of 2,000 years per person. As we increase the number of workers, the rewards decrease; this is because it operates similarly to a work-based system.
Regarding the current status, we have 248 workers controlled by the development team. Initially, we had 2048 active workers, but now we have 215 active workers, with only 248 workers remaining. There are six additional workers that are currently inactive.
To clarify, we have 215 active and six inactive workers. We acknowledge that there are some discrepancies in the displayed numbers, and we will address these issues to ensure clarity for our audience.
For more information, you can visit our website and access the documentation to learn more about our project, including details about our coordinator, validator, and wallet. We frequently update this information, including economic details. You can also connect to MetaMask to use our wallet and obtain test tokens on our testnet.
We provide tutorials on running a waterfall, but we do not use Docker; instead, we aim for more user-friendly nodes. Additionally, we offer instructions on deploying smart contracts using various programs and tutorials, including how to deploy token contracts like V Training.
We also provide guidance on running Uniswap locally on our network. It is important to specify that we do not have a partnership with Uniswap; rather, we utilize the open-source code of Uniswap. The version we are using is the third version.
This setup demonstrates that the migration of decentralized applications (dApps) is straightforward, even for relatively large applications like Uniswap. We have written instructions and conducted tests; our first testnet achieved about 2,000 transactions per second. Subsequent testnets showed improvements, with one reaching 3,600 transactions per second, while our latest testnet managed approximately 305 transactions per second.
Building your own version of Uniswap is easier than you think—open source code makes it possible!
In this session, we discussed the process of setting up a third version of Uniswap using open-source code. This demonstrates that the migration of decentralized applications (dApps) is relatively easy and straightforward, even for large applications like Uniswap. We wrote instructions during the summer and last spring, and we have continued to improve our network since then.
We conducted tests on our first test net, which achieved about 2,000 transactions per second. Subsequent test nets showed improvements, with one reaching 3,600 transactions per second and another achieving approximately 5,000 transactions per second. Our goal is to reach 10,000 transactions per second, as we currently face a limitation of 5,000 transactions per block. We are working to increase this limit to 10,000 transactions per block.
Many people have inquired about our code, which is currently stored in our GitLab. After completing a security audit, we plan to push the code to GitHub and make it open source when we launch the main net. We also have a Network Coordinator node in our architecture. In our first test net, our block creation worked without a coordinator, and we successfully simulated consensus.
Vladimir then provided insights into the block creation and finalization processes. We create blocks on each slot, calculating a creator list and preparing draft blocks. Each active creator retrieves their assigned transactions, signs the block data, and saves the block in the database before broadcasting it to the network. Once the coordinators reach consensus on finalization, they send a finalization request to the nodes. The nodes check parameters against previous optimistic finalizations and ensure that we have a complete optimistic finalization sequence.
If required, we retrieve blocks from remote nodes on the fly and initiate the finalization process. If finalization changes, we roll back the chain to a consistent state, calculate the optimistic finalization sequence of blocks, and apply the block transactions to the chain's state. Finally, we update the tips in accordance with the new state and send a response to the coordinator with the result of the finalization.
As we approach the end of our session, we acknowledge that we have been online for 1 hour and 25 minutes, and not all questions have been covered. We are happy to set up additional sessions with our management team, research department, or development team to address specific questions. Given that the development work has spanned over two and a half years, and more than a year in research, we believe it is best to conclude this session.
The recording will soon be available on our YouTube channel, and our colleagues will reach out with a list of questions for the next AMA session. We appreciate everyone's attendance and the questions asked. We look forward to sharing more details in the future and improving the process for subsequent sessions to minimize technical issues.
Thank you all for your participation, and we look forward to communicating with you again in approximately two weeks. Have a great day!