Learnings from Building Blockchain — Solana, Nervos & Lightyear (InterStellar) Meetup
On August 22nd, Solana CEO, Anatoly Yakovenko teamed up with Nervos Co-Founder, Kevin Wang, and LightYear’s Principal Software Engineer, Nikhil Saraf to introduce their projects and talk about their key learnings from developing blockchain infrastructure.
Introduction to Solana
Solana is a high performance blockchain that uses a concept called Proof of History to achieve a cryptographically secure and trustless time source.
- Telegram: https://t.me/solanaio
- Solana Github: https://github.com/solana-labs
Introduction to Nervos
Nervos is a network of scalable and interoperable blockchains built on top of an open network, built for the enterprise.
- Nervos Github: https://github.com/NervosFoundation
Introduction to Lightyear (InterStellar)
Lightyear, powered by the Stellar network, enables forward thinking financial entities to join the Stellar ecosystem.
- Stellar Github: https://github.com/stellar
Technical Discussion Panel
(Transcript below)
Raw Transcript of Video:
Sam: All right. So I think it’s going to be pretty casual, right, where we could open it up to Q&A first, if you guys want, because I know some people had questions about the individual things. We’ll maybe do one or two questions there and then we’ll go into more of a discussion, just in case there’s a burning question. Does anyone have any questions for any of the three about their presentations? Yeah, go ahead.
Man: I have a lot of questions. Maybe a good [inaudible 00:00:40] data availability [inaudible 00:00:40].
Sam: That’s actually one of the questions too. But like, before we answer the questions, could I just gauge the room? Who here is a technical or a developer? Okay. Who is the complete opposite and completely not technical? Okay. Cool. And then everyone else is somewhere in between. So I think you can answer in a kind of technical way, and we’ll…
Nikhil: So, again, so data availability. So I think the incentive to run a Horizon node is that you wanna make sure that when you need the data it’s there. And typically, if you’re one of the partners and you’re pushing a lot of data through the network, you wanna make sure that your transactions are going through. You don’t wanna depend on someone else’s node because that’s where the consensus comes into play, because your horizon node has its own trust model of who it trusts. So if you have to fall back on someone else’s node, you’re not really getting the guarantees that you would get if it was your own node. So then, it’s kind of on you to run your own highly available node, as well as make sure it’s always available.
Anatoly: For us, one gigabit will generate about four petabytes of data a year. So that’s a lot of data. It’s actually not that expensive. So 150k buys you a petabyte deployed. But it is a lot of data for individuals to store, kind of like… Our industry right now is built upon decentralization. And what that means is there’s low barrier to entry for anyone to participate in the network. So this seemed like an opportunity to me. And because of our particular implementation, we have this decentralized source of time before consensus. We can actually have a very cheap to verify proof of replication. And that allows us to stripe this enormous data set amongst any number of nodes that wanna just simply contribute storage without, like even high availability but some kind of medium availability. So to me, this seems like… In my mind, if we’re successful, imagine like anyone in the space is successful and 100 years from now there’s a Blockchain that’s around. This isn’t a data set of all economic activity for the past 100 years. That is probably the most valuable thing we’re building right now. So I’m really excited about that part.
Kevin: Just make sure I answer the right question. When you say data availability, what do you mean? It’s like…
Man: So, a lot of consensus protocols assume that the data is available, but the data could just not be available.
Kevin: Like fisherman’s dilemma, right? Fisherman’s dilemma. You’re talking about that?
Man: [inaudible 00:03:47].
Kevin: Yeah. Okay. So there are two parts to the question for [inaudible 00:03:54], right? So first is the consensus of the root chain, and then we use POW. So the POW consensus basically encourages data to, miners to make data available because you want to propagate your block as fast as possible so that other people can build on top of your blocks, right? If you withhold the data, then you’re not gonna be the longest chain. So that’s the sort of building mechanism on the consensus level to encourage data availability. So that’s one. You can withhold the data, but then you’re gonna fall behind, right? So you’re not gonna be the longest chain. So that’s in terms of consensus on the root chain.
In terms of, for us, like layer one, layer two interaction. So data availability comes down to, you know, what if the layer two operator, for example, withhold the data, and then how do you prove fault? Right? So that’s, you know, that’s not an easy question. I mean, there is Ethereum is for example, doing [inaudible 00:04:59] coding to be able to, you know, recover that data. But even then, I think a lot of time there is no way to prove fault. You can’t challenge the operator, basically, right? They can always review the data and then, you know, prove that you’re wrong. So basically, you can’t win. So in that case, there are two solutions. One is to do something like a mass exit to the main chain, like what plasma does. And then the other approach is to have…if you have sort of…we talk about side chains, right? Not stick channels. But if you talk about side chain that are built, like in the same form, then we can probably do something smart that migrate data from one site into the other without having to all exiting to the main chain. So that’s something we’re also researching now. Yeah.
Anatoly: So just to be a little contrarian, in proof of work systems, the miners have no incentive to keep the data set. Actually, most of them throw it away. Like, so you can hash the blocks without actually storing any proof of work, because you don’t care. All you care about is getting the block. So in Ethereum, it’s actually starting to become a problem because the data set is growing quite a bit and Bitcoin is still pretty small.
Kevin: Yeah, I think what I’m talking about, it’s when you do, like, win the lottery, right, like POW, then you want to propagate that block as fast as possible.
Anatoly: But you can throw away the rest of it, so you don’t have to store the rest of the chain, right? Like, there is…
Kevin: Yeah, but…
Anatoly: …not aligned incentives there.
Kevin: I think you were talking about verifiers, right? So it’s not the miner that find the block, but like the full nodes that receive the validation. Then, I mean, you can…
Anatoly: But if no one’s storing the full chain, then is it a Blockchain?
Kevin: Well, I mean, that’s what we’re doing. That’s where, you know, we have to give incentive for people to store it. Right? I mean, this is exactly like for knowledge-based platforms, we have direct token economics designed for encouraged for preserving knowledge, yeah.
Sam: Maybe, could you go a little bit deeper into the general token economic incentives?
Kevin: So, in Nervos, for example, you know, if you look at, you know, competition platform like Ethereum, the tokens are used to pay for computation cost, or unit of computation cost. So, for Nervos, the tokens are used to bond with the storage units and then to measure the space that you use to store data, right? So in other words, if you’re a user of the network, and you want to store your data entities into that network in the public Blockchain, you have to pay by locking your tokens, right? And then you’re…again, if you’re a miner that you do store this data, then you can get this, you know, from block reward to be able to store this data.
And we want to battle the problem of, you know, people like Ethereum, people pay once for transactions and have their data stored forever in a very, very [inaudible 00:08:09], you know, like, it could be there for 100 of years, but it’s all free, right? You pay a one-time cost. So what we’re trying to do is to say, for the user side, you have to pay an ongoing cost. And that’s incentive, that’s encouraging people to actually not to keep occupying this Blockchain, right? So they can always release their token from the storage. And then, you know, to get liquidity of their token, they can resell it. So to protect the full nodes and cost of full nodes running.
Sam: Would you guys also mind just going very broadly into the token economic structure of your projects? And kind of how it relates to maybe, incentivizing behavior that you want to drive towards a certain result.
Nikhil: So in terms of the stellar network, I think, the Lumen is mostly used just to…as a resolve when you open up an account. So this prevents people from just opening up accounts and sort of slowing down the network. And it’s also used as a fees to prevent people from spamming the network. So I think it’s really just to promote good behavior on the network.
Anatoly: For us, it’s really like an operating systems resource. If you ever, like, I don’t know, wrote kernel code, your processes and user space, they want resources from the kernel. You have to build them so you allocate file descriptors and all this other stuff. But ultimately, all that is a resource that accounts for hardware. So when a user submits a transaction, they’re asking for storage in the network. When they wanna do a computation, they’re asking for CPU. And those are effectively competitively priced. So, market priced. And our job is to make the system have as much capacity as possible to reduce those costs. So this is, you know, in our sense, our goal is to drive the fees to be as low as possible by making the software as kind of as fast as possible.
Sam: Very cool. So I wanted to switch it up just a little bit and instead of talking about the specific projects, maybe go from the perspective of a developer that may want to use your, you know, protocol or your platform or your product. Kind of generally, what differentiates you guys and why would someone choose to use your product over competing products? Maybe we’ll just go this way. Okay.
Kevin: You know, for Nervos… Okay, so there are two… The Nervos are layered architecture, right? So we have the base layer focused on…it’s a common knowledge base, so we can afford to focus not on, you know, computation cost. We don’t need to provide the lowest computations possible. And we want to provide security because that’s…as a common knowledge base, that’s what the users demand to be able to security, preserve the knowledge. So at the base layer, we prioritize security and decentralization, right? A censorship distance, those are all the values that a knowledge system will demand.
And then, the second layer is where really people build applications, and there will be different types of layer two solutions. You know, if it’s a cooperative game, then it could be, you know, state channels. If it is more of a, you know, a fast payment network, it could be, you know, specific build for that purpose. If, you know, if built for a specific industry, like for gaming and, you know, maybe there is a more non-fungible tokens, if it is, you know, for financial industry, maybe that’s more about [inaudible 00:11:56]. So there’s [inaudible 00:11:58] as possible. So all of these layer two solutions can specialize. But they can rely on the base layer to produce the decentralization and security so they can focus on their domain, you know, the requirement of their domain.
Sam: Maybe you guys can also, in addition to, why would someone choose yours over a competitors, maybe go into some of the use cases also about what you can use it for.
Nikhil: So I think in terms of why someone would choose Stellar, I did cover a lot of that in the presentation, but I will cover some of the highlights. I think that it’s relatively easy to use. So a lot of people don’t really know this part about Stellar, that if you want to issue a token on the network, it’s just a few lines of code. And issuing like, comparing this to Ethereum, if you want to issue a token on Ethereum, you’re really writing a full smart contract. That’s a lot of code you need to write. On Stellar, a token is kind of just like a distributed counter. So if you just want to track how many people are involved in your project, or how many people…how much value has been transferred over the network, Stellar is great for that because it’s cheap as well as really easy to code. And you can’t really have any bugs in that because it’s mostly just data. I think in terms of getting started, so we do have this project called the Stellar Build Challenge that allows people to contribute to existing projects or start their own projects, and Stellar does fund these projects with Lumen grants to keep the project going, and a lot of people join the community through this path, and we’ve actually hired a few people out of this as well.
Anatoly: So, for us, I think the selling point is performance. In my view, we can actually build a platform that is competitive to like a professional deployment on a centralized system. And because it’s a decentralized platform open to anyone, a developer can just jump on it and get all the benefits of very fast finalities. So right now our like Alpha is under sub-second, so around somewhere between 400 and 700 milliseconds for finality. That is close enough to be an interactive, like on-chain experience for humans such that they’re not annoyed with how long things take. But for developers, I think we’re maybe the most interesting, exciting part of the project. All of these technologies are coming together being integrated, and there’s a lot of fun opportunities to learn about consensus and scaling and performance and how to really fine tune and optimize things. So in my mind, this is like the coolest time to jump in and see what you can do. So if you guys are interested in learning Rust or building a really, really fast Blockchain, jump on our GitHub.
Sam: Maybe following up on that, if someone really did want to just start using you guys like today, right, for all three of you, what is available and what is kind of the first steps? Like, how would I literally start using you, like using your protocols and products?
Anatoly: Download the Rust tool chain, clone up the GitHub and go. That’s about it.
Nikhil: Yeah. So I think the best way to get started, I would say, is just go to stellar.org/laboratory, where you can actually just create a test account with two clicks. I think using that can follow the path of creating accounts, doing transactions and then maybe building apps and whatever your heart desires from there.
Kevin: Yeah, so for us, we’re still building the Nervos CKB, so the base layer protocol. So that’s not test net ready yet, so people can’t really build on top of that. But we do have a layer two solution we call Nervos App Chain that is ready. So you’re welcome to, again, go to GitHub and try that out. There is a, you know, EVM compatible site chain solution, there is a Blockchain Explorer, there’s a wallet that you can play with it. Yeah.
Sam: Thanks. So let’s shift back towards like the team building this project out. How exactly do you guys go and reach out to developers, besides things like this? Is there like a best practices in terms of ways to, you know, build a developer community, or just to like get people to look at your stuff? Because there’s so much out there, right? And so, how do you get mindshare in the Blockchain space towards developers?
Nikhil: So, we try to keep an active channel of communication with…we used to have a snap channel, and now we’re slowly shifting that over to key base. And this allows not just us to to talk to a community, but also other community members to talk to each other. And that’s how, for example, people form teams for the Stellar Build Challenge, as well as that’s how we push protocol changes through the community by having those connotations first in the chat channels and then potentially moving them to GitHub and to form the proposals.
Anatoly: For us, we’ve been open-source from day one, so really trying to engage developers kind of from the start. And this is the hardest problem in this space, I feel, because we’re building an operating system that’s hard enough. We’re also building a social network around it, which it’s also a super hard problem. And there is no secret sauce to building that. You just have to do the hard work of engaging people and getting them to try and really focus on solving a pain point that they have. And the pain point that we’re really good at solving is performance. So anyone that has problem scaling on Ethereum or any other chain, we can actually help.
Sam: So, that brings up a question that a lot of maybe first-time developers or like entrepreneurs may face, is that they see the potential and there’s so much to be done where you can solve a little bit of a problem, and then you run into another problem but you’re like, “I could probably solve that one too.” So maybe we’ll just do both of those. And then you run into a third problem. You’re like, “Well, I guess if we’re going to do two, we might as well do three.” And before you know it, you’re claiming that you’re gonna solve every problem under the sun at the same time, right? How do you kind of limit what your scope of your project is, and have you guys had any issues with that yourselves?
Kevin: Yeah. That’s definitely a pain. I think for anybody coming from engineering background, right? So your tool to attack complicity is abstractions, right? So for us, I mean, we wanna build the natural abstractions for developers, which means, you know, for us, you know, we have a concern to separate and compartmentalize in layers so that each layer focused on one specific concern that we can optimize it. So, it doesn’t have to mix together and then force to, you know, make hard trade-offs. So, yeah, abstractions.
Nikhil: I think the first step, I would say, is to be aware of that risk and try to not fall into that. So what we do is, we try to be very conscious about exactly what we want, say in the case of Stellar, what Stellar should be. And then we say no to a lot of things, because at the end of the day, it’s pretty hard to get a lot of people and hopefully the whole world using something like Stellar. So if we make it more complicated than what it needs to be to get everyone to use it, then not that many people are gonna use it. So we try to just keep things simple and figure out would some farmer in Africa be willing to use this complicated solution? And if we think that they might not, then we try to stay away from that.
Anatoly: For us, we really focus on performance. And so far, where we had to make trade-offs, I think, is really going after, like something like zero knowledge proofs and building a totally different model that requires, I think, really, really huge performance sacrifices to make it work. It is like a really fun research topic and I would love to spend a couple years trying to figure out how to make that work fast. But so far, it doesn’t seem possible. So when we do make choices in terms of what we’re building, we pick performance first, and then the second thing, we’re optimizing it for privacy. So that is kind of our clear design goals.
Sam: Cool. So, kind of going back to the developer side, what…and you guys have all kind of touched on this, but like what developer tools do you think are critical to knowing before jumping into, like, working with your projects? Like, what is the prerequisites that we should come with?
Kevin: Like, to build with our project? Okay.
Sam: Yeah. If I wanted to use your project, what should I already know? What must I know?
Kevin: You know, again, our platform, there will be multiple audiences, right? So there are people that are building layer two solutions. I think there are to then, you know, their own program languages and so on. They need to understand the interactive proof with working with the base layer protocol. So it’s more about complete economics. And then we’ll make that easy for people. That’s, you know, what we want [inaudible 00:21:42]. And then you have people working, building on dAPPS, on top of layer two solutions. You know, this is where I think it’s, you know, it’s really about…it’s not so much of building on top of Nervos CKB, but just knowing the specific platforms and their features, and, you know, what’s their trade-off to picking the right platform.
Nikhil: So I think the biggest thing, I would say, is like, have a mindset of security. Like, if you’re building a product, the security is kind of on you and it’s up to you to decide how secure your users are gonna be. And I think that combined with knowing any of the languages that we currently support, I think JavaScript is the most popular SDK that we have. I think combined with those, you can pretty much build what you want. And I think having that mindset of security is what’s gonna differentiate your app from any of the others.
Anatoly: For us, I would say the clear requirement is Rust. So it’s a high performance language. So, I would say that’s a pretty clear requirement right now, but we will enable more languages. Basically, anything that has a LVM front-end should be supportable. And our goal might be to be the first debugger for like Blockchain smart contracts. I’m surprised there isn’t one yet.
Sam: Yeah. Well, why do you think that is?
Anatoly: It’s just tooling is hard. Like, developer tools are hard. It’s always the last thing on anyone’s mind when they’re trying to get stuff out. Me coming from like 12 years of building stuff in embedded systems where tooling was hard as well. I think debuggers are very important for developers to actually get stuff done.
Sam: That’s an interesting point. I know all of you have really interesting backgrounds. I don’t know how much time we have to go really deep into it, but maybe you guys could talk a little bit about your backgrounds and how they relate to your current project. I know you had some really interesting stuff on like decentralized exchanges, and I know you have some. So maybe take a moment and then talk about how your past relates to what you’re doing now, and maybe also how people with really interesting backgrounds out in the audience, they can kind of find a place for themselves in the Blockchain world.
Kevin: In terms of interesting background, I feel like for most of us coming from engineering background, you know, this entire Bitcoin, the Blockchain, you know, innovation is really just the last several years. So, you know, for example, I was a…I worked as a software engineer at IBM Silicon Valley lab, down, you know, in San Jose. So I wasn’t really doing a lot of, you know, Blockchain or, you know, cryptoeconomics research or cryptography research. I was doing more of a, you know, data management and big data solutions at the time. So I think it’s more just general, like computer science education, and knowing about distributed systems, algorithm, data structure. So I wouldn’t put a very high barrier for people who wanna come to this world and who want to become a Blockchain engineer and developer. If you’re interested and you have some spare time to play with it, you’re probably halfway there.
Sam: What about for non-developers?
Kevin: For non-developers, I mean, it depends on if they want to become developers. Yeah. I think a good place to start it’s probably Ethereum smart contracts. So it’s relatively easy, you know, easy to pick up a programming language, or they can start work with JavaScript which is kind of similar, right? And go from there and learn about the base principles of, you know, Blockchain systems and start trying to play with the smart contracts. That’s probably the best.
Nikhil: Yeah so, for me, I came from, I guess, more of an infrastructure background, so I was at Salesforce where I worked in the queuing team, and also at Duetto off of that, which is a startup that works on dynamic pricing. And with that, I sort of wanted to learn more about exchanges and trading. And that’s when I came to Lightyear to sort of learn more about how the decks works. And now, for example, I’m currently building trading bots to work on the decks. So I think that that was kind of like a very natural path for me. And I think that anyone with a solid understanding of distributed systems would have a good opportunity to get into Blockchain and be excited about it.
Anatoly: So I spent like 12, I think, or 13 years at Qualcomm, basically optimizing operating systems. I feel like I was born to build this operating system because I spent literally 12 years optimizing hardware and optimizing very large deployments of this hardware on like very adversarial networks throughout the world. So I think one of the projects I worked was called Brew. If you guys ever had like a CDMA flip phone, like a Motorola Razor, they all run Brew. There were 500 million of these devices, and OS ran from like a phone with two megabytes to like 128. So we had to really count every bit and byte and make it as fast as possible. And that’s what we were doing. We were making a consensus work by just making the single node like really, really fast because they actually can be. We have the hardware to do so.
Sam: Cool. So I wanna wrap up the panel a bit. My last question before we open it up to Q&A, is just where can people learn more and what should they focus on?
Kevin: To learn more about our projects? Okay.
Sam: Or in life, if you have life advice or something.
Kevin: Lean more, wow. Okay. I’ll just focus on our project. That’s an easy question. So you can just go to our website, nervos.org. You know, from there, you can join our community. We have a Telegram channel and email list. You have a bunch of forms, you want to be more involved. Yeah, just go there.
Nikhil: So I think for developers, I think the best place to start is stellar.org/developers. And from there, you can see the APIs as well as different walk-throughs that we have on how to get started.
Anatoly: Solana.com. You can find all the links there. There’s Telegram, there’s GitHub, there’s Discord, whatever you guys like.
Sam: Cool. A quick round of applause and then we’ll open it up to Q&A. Cool. Who has a question?
Man: Yeah. So, anytime someone talks about scaling Blockchains or like getting really high transactions per second, I always like to understand to what degree they’re choosing just a corner and like the scalability trilemma versus, like, bypassing the trilemma.
Anatoly: The trilemma is BS. It’s not [inaudible 00:28:54].
Man: Well, right. Yeah. And plenty of people are trying to bypass it. Like, obviously, using hardware techniques or sharding, like are all claiming to move in a dimension, not in the trilemma, but then there’s also plenty of projects that just say, “Well, hey, we’re gonna sacrifice decentralization, get really high transactions per second, you know, say we’ve had a breakthrough.” And really, it’s just, they’ve kind of made a trade-off that other people weren’t willing to make.
Anatoly: So, for us, there isn’t a trade-off because we’re not sharding, so we’re not really sacrificing the security parameter of the network. We’re still limited by the slowest node in the super majority. Our goal is just to make that node as really fast, and it’s actually very doable for very cheap. Our test bed machine is off the shelf, in Nvidia Gpus. So, for 1080 ti’s it’s under 5k. You can do the full million elliptic verifications you need per second. The latest generation, one card can do three million per second. So how we’re scaling and are aligning our project is with Moore’s laws it’s working today. Clock speeds are not increasing, but core accounts are. So we’re making the software as paralyzable as possible. So in two years from now, we’ll have 8,000 cores on a $700 card. Four years from now it’s gonna be 16,000 cores. My goal is to do a billion transactions per second in 10 years, right? And that’s all doable as silicon gets better.
Man: You said you’re not sharding, but with that amount of transactions per second, I also imagine… I mean, you mentioned yourself that your data is gonna scale a lot. So the data you do plan on sharding or striping.
Anatoly: Yeah, the data is striped. So, we use a proof of replication technique to basically stripe it and replicate it to a very large number with a very high availability. So imagine like a thousand copies of a single slice that’s throughout the network. So, with that much availability, there’s, you know, a thousand nines of guaranteeing of it being a copy of it somewhere. And that is, I think as close to…that is the ultimate, like, trade-off there, right? With pure decentralization, we have a full copy in every node.
Man: So what if I have to compute state that I don’t have locally on my node? Do I have to retrieve that through the network first? And then…
Anatoly: Yup. And you would need to effectively pay for it. And so, there’s an incentive model to kind of pay you to store it, pay you to retrieve it, stuff like that.
Man: Micro-payments for retrieving data?
Anatoly: Yeah.
Man: Cool.
Man 2: Hey, guys. So, quick question regarding scalability. So a lot of you guys are trying to solve the issue of scalability by coming up with new consensus algorithms, but if you guys had a better kind of underlay network, right, a better infrastructure so that your packets are in blocks that are propagated through traditional internet, do you think there could be changes to your protocol if you can make assumptions around the underlying network that all of your miners, and, you know…
Anatoly: Dude, I could, like, talk hours about problem with…just with networking. Yeah, multicast, you know. It doesn’t work on the internet. Like, we can send a packet of data that’s supposed to go to a bunch of nodes, and switches could actually do all the re-transmission for us, but it doesn’t work on the open internet. So we have to build these protocols around that. And there’s a lot of difficult problems there in terms of just even verifying UDP packets where they come from. So there’s a lot of interesting optimizations there. So if there’s projects that are building that, I think that if the space succeeds, those projects could accelerate that and actually like 10X the performance. So, I don’t know, but which project are you talking about?
Man 2: We can talk offline about it.
Anatoly: Okay. Networking is hard.
Man 3: Yeah. You mentioned briefly, your timing synchronization, I guess innovations and that enabled higher transactions per second. Can you just talk more about that?
Anatoly: Sure. That doesn’t actually enable throughput. What that allows us to do is kind of decouple consensus from throughput. So what we’re doing is really, it’s called a verifiable delay function. And the verifiable delay function is the ledger data structure itself. So a ledger, right, is the single source of truth in the network, but it’s also our clock. And it’s a clock that exists before consensus because you can append to this ledger, and any petition that you append to you’re generating time. So the source of time, you can think of it as a water clock, and nodes in the network can use this source of time to get a synchronous complete view of the entire network and they know that everyone else has the exact same view and they can make decisions based on that. And that allows us to shortcut a lot of the messaging overhead.
It’s very similar to what Google does with its true time in the spanner database. So they have these atomic clocks that they synchronize by hand. We’re simply using a cryptographic function to generate this source of time, simply.
Sam: I know we’re getting kind of deep into this. Does anyone have like a simple question?
Anatoly: An easy question?
Sam: Yeah, like an easy question? Like, maybe from a non-developer.
Man 4: Not for Nervos, but for Stellar and for Solana. You were working at Lightening, so this is all to Solana. Why the focus on putting things on chain, not off chain?
Anatoly: Well, it’s a cryptographically secure computer. If we can make it fast, we can actually start moving more use cases into this model. And for me, what this model really enables, it is like privacy in the internet. We have an open database of all these transactions, so we have to build everything with privacy in mind because we can’t share your public data. It’s shared publicly, right? We can’t share your information because it’s all stored in this public ledger. So we actually have to start building applications with privacy first. And it’s ironic that it took an open database to give us a path to privacy in the internet. So if we can make it fast and we can make it permission-less and keep those properties, we can actually start getting rid of all these vertical sandbox technologies like Google and Facebook and Apple that are really designed to kind of keep us in a single marketplace and steal all our data and really sell it, right? And it just sucks.
Man 4: So in the interest of privacy though, why form a single data set that has everyone’s information instead of separating it out into off chain and stuff?
Anatoly: Well, if as an engineer you know it’s going to be open, you build it to be secure and private. So we use cryptography, right, to hide all this data, to actually prevent you from…and secure you. In a very simple case, a token is a resource of hardware. When I talk to my thermostat, it doesn’t need to know about my Google account. I can just send it a little bit of resource for that one transaction over self-generated key pairs that we just created. And those disappear and we don’t have this, like, Google account relationship anymore. It’s literally me enabling a piece of hardware to do its job and only that. And that doesn’t exist right now, and I don’t know why. Right? But we can actually build that and enable that.
Sam: Any of you guys wanna take a crack at it?
Nikhil: Yeah. So I think for us, so what Lightyear is trying to do is it’s trying to get partners to do a lot of the transactions actually off chain, but if they want to cross the border and talk to another entity that is also dealing with the same tokens or whatever, they would then have to go through the Stellar network and then that would have to be on chain. So it’s kind of like we’re trying to use a mix of both.
Kevin: Okay. The specific question actually doesn’t apply to us, but, you know, our view of this is, there’s no…you know, we can’t capture everybody’s, domain-specific requirements, right? So for some domain, they may have privacy concerns, they may have both data and algorithms running under secure [inaudible 00:38:09]. And then for some other projects, you know, it could be something totally different. You know, for enterprise applications they may not, you know, for competitive reasons or [inaudible 00:38:18] reasons, they just can’t put the algorithm on chain. So for whatever reason it is, we allow people to choose their own proper, you know, settings and motor run their computation and then we don’t care about how they generate it. We just look at…we allow people to define their own semantics in terms of what is, you know, what does trust mean, right? So in terms of data. And then that defines the trust semantics of the Blockchain. So, yeah. So we totally welcome, you know, off chain computation and solutions.
Sam: Again, does anyone have an easy question? Like a super simple question that you’ve always wondered, maybe. It doesn’t have to be about these projects in particular. All right. Yeah. How do we get more people to use these things? What’s missing? What do we collectively have to do to get people to care?
Anatoly: I think that once scale is there, developers will start building cool things for it and people will start using it because they’re not giving up their privacy. Like, I think adoption..so I was building this like CDMA phone. We had 80% market share. And Apple came out and within a year it went the other way, 80% smartphone market share. So when there’s like a catalyst that things become obvious to people that this is awesome, it’ll happen like that. Until that happens, until we actually build all the tools and infrastructure for that to occur, it will be hard, but when it happens it will be very fast. And it will be obvious in retrospect. Yeah, this thing is awesome.
Nikhil: Yeah. And, just to add to that, I think there also needs to be some element of trust by the general public. I think when that does happen, people are gonna trust the Blockchain and all of that a lot more. I think right now people just outside of the bubble that we’re in right now, they just think of Blockchain as a buzzword, and they’re not really aware of exactly what it is. And once that barrier’s crossed, I think that’s gonna help with adoption.
Kevin: Yeah, I think definitely what they said. Scalability is definitely a hurdle. But I think it will be solved. So I’m actually kind of optimistic, right? So I think there are gonna be a wave of applications coming onto the Blockchain platforms, and especially optimistic about like financial applications. And a lot of it comes down to whether we have regulatory certainty, and, you know, what type of financial products, you know, we can use this new platform to enable. I think once we have that, it’s gonna be a whole new world. Yeah.
Anatoly: I hope you’re optimistic. I think, just to add to that, this technology is just…it’s really cool because it allows us to come to agreement on something without a third party. Right? Like, all of us here can come to agreement on a source of truth without trusting anyone else to put it together. And that is the beauty of it. Like, we can use this plus cryptography to create applications that have never been possible before, and they can actually solve real world problems. Like, right now I send like money through my bank, it costs $25, because they’re a bank and I have to use them, right? But with cryptography, the costs of that are pennies. Like, it actually is the cost of changing numbers and memory in a computer. So we can take all this wealth that’s being spent on sending money around and give it back to the world economy and actually create wealth. And this is, I think, for an engineer, this is like the biggest opportunity in the world because I think Gartner said that we spend like $2 trillion in moving money around. Like, which is absurd, right? Like, why are we spending that much money on money?
Sam: Yeah. So I think that highlights an interesting area where suddenly…well, it’s been since the internet, but suddenly as a developer, you can make real world impacts, right? It’s not just about moving bits and bytes. Those changes in bits and bytes are really doing things in the real world. They’re paying someone’s rent or, you know, all of that. As a developer, how do you learn all of the different moving pieces about a Blockchain business, right? Because there’s so much, right? There’s so much to learn. It’s overwhelming at times. Like, even as a developer, maybe you’ll code something, but then there’s like a legal issue or something. Or How do you even handle that? Or do you have to just kind of do it and run into a wall every once in awhile?
Kevin: I don’t think it’s different from other types of new, brand new technology that evolve very fast. When you go online, you typically find out of date tutorials, you typically found things that are no longer maintained and things evolving very, very fast. So I’ll recommend going to events like this to meet people and see what people were doing. You know, go to conferences and get the most up-to-date technology. That’s probably the best. And then just so willing to play with Beta software and just experiment and, yeah. I think a lot of it comes from that. Just tolerate ambiguity because there’s gonna be a lot of that. And then if you fall, that’s fine. Just try something else. Ask for help, go to community, you know, forums, you know, slack channels and everything. Yeah.
Nikhil: I think that’s one thing that when I entered the Blockchain industry, I was completely surprised by it positively, that a lot of the projects are actually all open source. So there is a competitor [inaudible 00:44:37], I guess, software companies. There’s a lot that you can do in this space without actually getting blocked by all these legal issues that obviously does come about every once in a while. Like, for example, Solana trying to encourage people to take their code and do things with it. And I think that, if you create a project, I would say that that be open source, because you will be positively surprised by how many people contribute to your codebase and help your product.
Anatoly: Just, you mentioned legal issues, I think that is the biggest gray cloud over this whole space right now in the United States. I think it will get solved sooner or later because there’s simply kind of too many smart people working in this technology. So just go build stuff. Like, don’t worry about it.
Sam: So I personally find the open source, like closed source thing, very interesting. Could you guys talk about kind of the design decisions or the decision in general of making your projects either open or closed source? And maybe the thought process behind how you thought it through?
Anatoly: So, for me, I started programming when I was very young. This was in the Soviet Union. And I really continued in the United States and I started working on Linux, and that’s an open source project, and I just learned so much playing around with it. And I was there for the legal battle between SCO and IBM, and kind of like as the open source ecosystem matured. And I saw projects that were really promising, that stayed full source and they failed even though they might’ve been better technologies when an open source project had all their code out there and those communities grew and kind of created these awesome ecosystems. So from my perspective, I think anyone that’s building Blockchain stuff closed source is shooting themselves in the foot, because the hardest thing in the space is getting people to understand what you’re doing and getting that information to spread and be absorbed by the rest of the world. And if you put any brakes on that, you’re just killing yourself. Like, nobody’s gonna care about a closed source Blockchain 10 years from now.
Nikhil: Yeah. I think that’s pretty much exactly what I was thinking about. And I think if you’re not allowing people to contribute to your codebase, then you’re just harming yourself and you’re just giving other people that are encouraging others to contribute a better chance of being successful. And, yeah, I think that’s kind of one of the things that we keep in mind when we try and open source things. But I think sometimes you do have to keep things closed source. And I think it’s also important to consider maybe you can open source a small part of that, you know. And anything you open source, I always believe is going to just get better by contributions from other people.
Kevin: Yeah. I mean, it’s not too different here. So Blockchain system in general, it’s all about trust, right? So how do you gain trust of the users if you don’t let them examine your source code? Right? So, what system you’re running? And also, just, you know, Blockchain system in general, or public Blockchains especially, are running in the open. So there are gonna be people that constantly think about ways to attack the network, right? So you want it to have, both…if the source code is in the open, then anything that happens, you all of a sudden have your own community to try to help you and, you know, figure out the problems and evolve and go from there. Right? So, you know, for us, we’re currently temporarily closing source of network CKB, but we’ll open it in a few months. We’re running some experiments and, you know, once the sort of source code stabilizes, we’ll definitely open source everything before test nets.
Anatoly: Just do it now. No one’s gonna steal your code, dude. If like, you actually imagine somebody building a team, taking your code or running with it, they have way too much time on their hand.
Kevin: I agree. It’s really not for competition reasons because, you know, we’re trying a few iterations just to prove things right. So for some, that’s not, you know, the time yet for people to come in because that’s just…we’re not committed to specific design one way or the other. So once we do know the direction we go, then, you know, we’ll make it open and people will come and contribute.
Anatoly: All our warts are in our code base. There’s a bunch of ways to, like, knock down the test net right now. If you do so, we’ll give you a T-shirt. I’m still waiting for somebody to do so. We did have a contributor that was like contributing in the weekends, and we hired him because he was awesome, and it was like, “Why don’t you do this full time?”
Sam: Any questions from the audience still? Okay. Maybe final question, biggest tip that you have for an aspiring developer in this ecosystem?
Kevin: Just find a project you like and start contributing. Don’t ask for permissions, right? So everything is all in the open, specifications, economic discussions, codes and building smart contracts. It’s just don’t wait. Yeah, just get started.
Nikhil: I think that it would be great if you could look at existing projects, see what people are doing, and then use that to inform yourself about what your project should be doing and that would allow you to not recreate what other people have already done, and maybe contribute to an existing project.
Anatoly: I think it’s really hard to kind of get going. So find something you really like. I don’t know, it doesn’t even have to be what you normally do. You could be a JavaScript programmer, start working on encryption. You know, like, do whatever really inspires you, because we’re in such a really cool and early stage in this field that you can do anything. So, go do what you really love.
Sam: Yeah. I’ll add one too. Just read a lot. There’s a lot of information out there, maybe too much information. So find a place where you feel comfortable, like, getting information and just, like, go there regularly and try to learn as much as you can, because it’s ultimately not that hard. Right? It’s doable.
Anatoly: Yeah. It’s all doable.
Sam: Yeah. So, I’ll encourage you guys to, like, keep at it and that you can do it. So, thank you, everybody.
— —
Want to learn more about Solana?
Check us out on Github and find ways to connect on our community page.
