Genesis Cohort 1 Onboarding
40/1000 Genesis Founding Members Onboarded
40 members from Testnet phase 1, Phase 2 and Winter Special Testnet were selected and successfully onboarded into the first cohort for the Genesis Token program. Congrats to all 40 members! They are Testnet MVPs and top rankers on the leaderboards of the completed testnet phases. Their participation and contribution to testnet and the community helped the project to get to where we are today, and we’ll continue to count on them to become the network’s first block producers and further build on Coda’s success. (Check out the latest press release.) Last week we had a kickoff call with them, and they asked many good questions. Check out a recording of the video here and scroll down to check out the written version of the questions and answers.
Who are they?
We’ll feature Genesis founding members on our website. Check out the profile of @garethtdavies and who built a Coda block explorer that probably many of you are using, and the profile of @Alexander who shared guides in Russian to help Russian community members to get connected to testnet. More profiles to follow!
How can I also become a Genesis founding member?
There are 960/1000 spots left! We hope to onboard a much bigger group next time. Genesis founding members are selected from the participants engaging in testnet challenges. Check out the challenges here. By completing challenges, you’ll earn a spot on the leaderboard.
When will the next Genesis cohort be selected?
After Testnet Phase 3 ends, a new cohort of Genesis founding members will be selected. We will consult the phase 3 leaderboard, and the Testnet MVP and Community MVP positions.
Genesis Cohort 1 Kickoff Call: Q&A
Last week was the kickoff call of Genesis cohort 1. During the call, we shared some insights into the Genesis program with each other and there was the opportunity to ask questions. A recording of the call is available here.
- I really appreciate the O(1) team’s efforts around building a robust community of node operators, but at the same time, is there work being done to attract users? (49:05)
The way we’re approaching this is in layers: The first thing we did was build the core protocol, which we focused on for the first year and a half. Next is building a strong foundation of active block producing community members, which is where we’re at now. We’ve been really successful so far with building out a robust, technical community. In fact, we’re one of the protocols with the most decentralized and most number of block producers, when measured against comparable networks.
The next stage would be focusing on developers and end users, which is what I’m assuming you mean when you say ‘users’. Thinking about and catering to developers and end users is for sure really important and something we have started looking into, but we are taking it step by step and making sure that we have the first two layers well developed before changing our focus to the third layer of ‘users’. When we get to that stage, we will make sure that we have a really great developer ecosystem (e.g. developer tooking, sdk. etc.), compelling use cases and applications to build on top of.
- What if I wanted to ask my family member to join Genesis? (23:03)
We welcome you to onboard your family member, friends, and other contacts, and teach them how to run a node and become block producers. In order to qualify for Genesis, they need to be able to independently operate, validate on their own and be an ambassador for Coda, since the objective of the Genesis program is to build a strong community of node operators. The onboarding process and eligibility requirements to become a Genesis founding member are also designed in such a way to check this.
- What are the main use cases of Coda? Because one of the biggest threats in launching new projects is that they may have good tech but zero adoption. What are your thoughts? I think it may boost interest to the project if people see future use cases. (25:59)
Great question, and this is something we’re actively working on. We see Coda as ‘open programmable money’, which is meant to fill the original vision of cryptocurrency, in a way. When Bitcoin was started, its original dream was to be open, decentralized “digital money”, which was supposed to be this internet money everyone could have free access to. However, we’ve seen Bitcoin turn into “digital gold”, and there hasn’t been anyone to take up the mantle of the original vision. We also see that many that are active in crypto communities are looking for one thing — decentralization. We believe that Coda can provide both, with the types of applications that Coda will support and the development experience it’ll bring.
In addition to that, we see an economy of participants who want to generate peer-to-peer cash applications. It’s been really hard for developers to get going with existing protocols because of how difficult it is to build on top of them. For instance, for a developer to integrate Ethereum with their application, they first need to learn a whole new way of development and programming. With Coda, our vision is to make that as easy as possible, as simple as a few lines of code so that anyone can get going in 5 minutes. We’re really excited for this and we’re also looking forward to eventually use SNARKs for privacy beyond money, as a way to create more fair platforms and fair digital experiences.
But we are really looking to the community to shape how Coda will be used. The team at O(1) Labs created the protocol, but the beauty of an open source project like this is that once it’s launched, it will be up to its community to come up with new innovative ways in which it will benefit people around the world.
- The 1000 genesis founding members will each get 66k tokens for a total of 66 million tokens all locked up. This is 6.6% of 1 billion. And how will the other 934 million tokens be distributed during the mainnet launch? (Discord - #genesis-founding-members)
We will be releasing a comprehensive overview of the distribution of the entire initial supply shortly.
- What will be my uptime requirements for staking to make sure I don’t lose my Genesis grant? For example, if my node goes down due to an upgrade or something like that, how much time do I have to get it back up before losing my Genesis grant? (45:52)
We haven’t determined the exact threshold of the required uptime yet, but ballpark number, we’re targeting about 90% uptime, which is not that stringent compared to other protocols. The way we’ll measure this is: dependent on the inflation rate, we expect you to win a number of blocks that falls within a statistical range, and as long as you fall within this interval, you will not lose your Genesis grant.
The high level answer is that we’re not going to be unreasonably punitive with this measure. Our goal is to make sure that core block producers (ie. Genesis Founders) are keeping their node up to make sure the network is secure. So if you are in good faith trying to keep your node up with reasonable consistency, you will not lose your Genesis grant. E.g. if you leave halfway through the first year, then you will loose your Genesis grant. We want to come up with something that is fair and that only punishes people who are actually inactive, and not people who are trying their best.
- I’m wondering about the SNARK worker fee. If the SNARK worker fee is too low, for instance, not many people will want to do it; however, if it is too high, everybody will be fighting to do them. How will SNARK worker fees/rewards be determined? (33:37)
The SNARK worker fee will be determined by free market dynamics based on supply and demand - a “snarketplace”, if you will. Also, we are devoting a part of Phase 4 of our Testnet to testing out the economics and monetary policy hypotheses around what the different fees (transaction fees, SNARK work fees) might be.
We’d also like to mention two other considerations for SNARK workers:
- Tip: you will have idle computing capacity from staking that you can devote towards SNARK work to earn extra SNARK rewards.
- We also expect Coda’s SNARK construction and system to improve over time, so SNARK work is likely to become cheaper computationally and more accessible as we get closer to mainnet.
- What’s the demand for using Coda at the very beginning? If the demand is small, what’s the incentive to run the SNARKER node apart from getting the inflation rewards? (53:10)
To clarify, the SNARK rewards are different from the inflation. The inflation schedule (shown in our economics white paper) is referring to block rewards. So those are going to be rewards that are won, regardless. SNARK rewards will come out of transaction fees that end users pay.
In terms of what’s the demand for using Coda at the beginning, we believe Coda’s differentiated technology will resonate with users. Coda is going to be an incredible platform for building cryptocurrency-enabled applications, since it’s so much more lightweight than any other cryptocurrencies out there. Instead of downloading gigabytes of data, users can just download a zk-SNARK proof to verify and have full security of the protocol, regardless of what device they are on (e.g. smartphone, browser, etc.).
So echoing what was described earlier, we are developing Coda step-by-step: first by building the protocol and making sure it’s rock-solid, then cultivating a decentralized, technical community of block producers, then creating a great developer ecosystem and proposing end use cases. We believe that by approaching it this way, we will cultivate demand for Coda step by step together.
Cryptocurrency is also such a new space still, and as more people move to adopting cryptocurrencies as a means of exchange that’s native to the internet, there’s great potential in us benefiting from those industry-level advancements as well.
- There is a Genesis requirement to stake all your Genesis coda, but are we able to hold back any of those tokens to use as transaction fees, for instance? (21:08)
Per the rules of the Genesis program, you need to stake all of your Genesis tokens for 1 full year upon mainnet launch in order to keep them, and they won’t start to vest until the 1 year mark. So you cannot use tokens from the Genesis program as transaction fees. However, you can consider Genesis tokens to be “starting capital”, because once you stake, you will get block rewards. Block rewards are not subject to any lockup requirements and you are free to use those block rewards however you want, whether it’s for transaction fees or other purposes.
And a side-note that’s also interesting for block producers:
Staking on Coda’s consensus mechanism, Ouroboros, also means that, in general (if we disregard the Genesis program), you don’t have to lock those staked tokens. You can use them for transaction fees, but it just means you’ll have less the next time around when there’s a new epoch.
- If Genesis is focused on onboarding 1000 participants, when should we expect mainnet launch? Is it based on the amount of validators onboarded or based on the software being ready? (56:42)/(25:06)
Mainnet launch is based more on the software being ready and us being sufficiently confident in our ecosystem of validators and community. 1000 Genesis participants is our goal and it is an ambitious one, but we think it is achievable. Getting to as close to 1000 Genesis members is also important to ensure that we are the most decentralized and secure network. We intentionally made it very challenging to make it into the first Genesis cohort (so you should pat yourself on the back for clearing this high barrier to entry!), as you will serve as the backbone of the community.
As we scale to up to 1000, the technical barrier to entry will also be lowered, because we are investing in building out the software so that it will be easier to run a node on Coda (with things like a console wallet). So more people will be able to easily stake on the network. The way to get into Genesis will shift in time from just opening the software and running a node, to running a node and other valuable contributions to Coda Protocol or its users, for example developing tooling, being an ambassador, etc.
We will launch when the network is ready, and right now we have planned to finish Testnet Phase 3, Testnet Phase 4 (which will focus on testing the economics and building on top of Coda), and Adversarial Testnet—after which will be mainnet launch.
- When approximately do you plan to launch mainnet? (31:14)
As we’re working on cutting edge technologies and facing really new technical challenges, it’s difficult to predict how things will go. Mainnet will go live when the software is ready. To give you more insight on what’s on the roadmap, we’re planning to complete these testnet phases before mainnet: testnet phase 3, phase 4 and the adversarial testnet. In each phase, new features will be introduced into the protocol and tested together with the community, so that we can head to a strong mainnet.
We expect to launch mainnet by the end of 2020, and we will give the community ample notice in advance of launch so everyone can prepare for staking on mainnet. We advise you to keep an eye on your mailbox and Coda’s discord to stay updated on all these exciting developments.
- Is the minimum recommended SNARK worker still at 16 CPUs? (51:37)
If (on one node) you are running both your block production and SNARK work, then, at the moment, 16 CPUs is the minimum. This is because we have yet to build sound logic into the infrastructure to prioritize block production over SNARK work, but this is something we’re working on.
But if you’re running just a SNARK worker, you can get by with as low as 4 CPUs, to keep up with the network. Granted, you’ll produce 4x less SNARK work than someone running on 16 CPUs, but it should still work.
- Will the GPU be Cuda or OpenCL? (52:54)
Cuda for now.
- How will token vesting/locking be technically implemented for community validators? (44:07)
We will be expanding the types of transactions you can do, so we will support arbitrary predicates on transactions. And on top of that, we will be implementing time-locked accounts, and then vesting will also be baked into the protocol to support this. For actual implementation details, it’s still in the design phase currently, but if you keep your eye on our Github repo, we’ll have detailed specifications and RFCs (Requests for Comments) in the coming months.
- If there will be 1000 validators in the community in total, then in theory they can delegate coins to one validator. Is there any minimum number of actual validators nodes that need to be run? (39:50)
We are not setting a minimum number of validator nodes that need to run on Coda’s network, since there are many ways that these ‘rules’ can be circumvented, like through civil attacks. Instead, we are designing our network from the bottom up and cultivating a strong, dispersed community of active participants, to make sure it’s as decentralized as possible.
Of course, if we see all the activity being concentrated on one validator, we will take steps to mitigate that, but if we do our job well and focus on developing a strong community, we should be able to avoid this problem.
- What can developers expect regarding the network performance, specifically transactions per second (TPS), at mainnet launch? (58:50)
So Coda is approaching this in a slightly different way. We intend to target developers and get them excited about Coda not via TPS (which isn’t that relevant until the network is being used heavily anyhow, which will take a while after mainnet launch). Instead, we will focus on Coda’s ability to let people run their applications on any device without sacrificing security or delegating to some third party, due to our light blockchain.
For most protocols, increasing TPS is a philosophical decision because it comes at the expense of decentralization. For instance in Bitcoin, to increase TPS, you need to increase block size. When you increase block size, most people on the network will be priced out of validating, since it requires a lot of computational energy to be able to do so. And so the validators become concentrated amongst a small group. Coda’s different. Because of our succinct blockchain, we do not need to choose between TPS or decentralization.
When the time comes for us to need to scale up TPS, we can do so (we have many possibilities in mind to achieve this) and it will be an engineering question, not a philosophical one.
For more details on this, check out our blog post on a concept called Scalability-per-unit-of-Decentralization (ScaDe).