Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Jack O'Holleran: SKALE Labs – An Ethereum Scaling Solution Using App Specific Blockchains

Episode Date: August 11, 2020

SKALE Network's modular protocol is one of the first of its kind to allow developers to build application specific blockchains. These are interoperable and compatible with the Ethereum mainchain, and the entire Ethereum ecosystem. They provide the benefits of decentralization without compromising on computation, storage, or security.The focus of SKALE Network is slightly different to other scaling solutions, many of which we have had on the show in the past. SKALE Network aims to scale smart contracts, not necessarily transaction throughput. Think of it as a highly performant Ethereum as a service side chain, where developers can deploy their own app specific blockchains. Within the scale network, their dapps will benefit from thousands of TPS with zero gas fees, and addons like file storage. In the future, it’s possible that SKALE will support other addons like machine learning. Jack O'Holleran, CEO and Co-Founder of SKALE Labs, talks about how they are tackling the scaling issues on Ethereum.Topics covered in this episode:Jack's background and how he got into cryptocurrencyJack's thoughts on the problem of scaling on EthereumWhat is a SKALE node and how to start oneComparisons to Cosmos, Polkadot and Eth 2.0 shardingThe SKALE NetworkThe purpose of the SKALE Manager and how it interacts with validators and nodesCreating a dapp on the SKALE networkWhat is the future of access to connectors - are stores an option?How security properties work on the networkWho are the users of SKALE and how does one onboard to the networkThe NODE Foundation - the launch and grants availableEpisode links: SKALE Labs WebsiteSKALE WhitepaperSKALE DevelopersSKALE DiscordThe NODE FoundationSKALE Labs TwitterJack TwitterThis episode is hosted by Sebastien Couture & Sunny Aggarwal. Show notes and listening options: epicenter.tv/352

Hi, I'm Sebastink with you, and you're listening to Epicenter, the podcast where we interview crypto founders, builders, and thought leaders. On this show, we dive deep, learning how things work at a technical level, and we fly high to understand visionary concepts and long-term trends. If you like Epicenter, the best way to support us is to leave a review on Apple Podcasts. If you're on a Mac or iOS device, the easiest way to do that is to go to epicenter.rocks slash Apple. Today our guest is Jack O'Holleran. He's a CEO and co-founder of Scale Labs. They're building the Scale Network, which is a scaling network for Ethereum. And we're going to say scale a lot of times in this episode.

So Scale Network allows developers to build application-specific blockchains, and these are intrappable and compatible with the Ethereum main chain and the entire Ethereum ecosystem. We've had several scaling solutions on the podcast in recent months, but the focus of Scale Network is slightly different. Their aim is to scale smart contracts, not necessarily transaction throughput on the Ethereum main chain. So think of it as a highly performant Ethereum as a service side chain

where developers can deploy their own app-specific blockchains. And within the scale network, their DAPs will benefit from things like thousands of transactions per second with zero gas fees and add-ons like file storage. And in the future, it's possible that scale will also support other add-ons for things like machine learning and so on. And with that, here's our conversation with Jack O'Hollerman. We're here with Jack O'Hollerin. He's the CEO and co-founder of Scale Labs. Jack, thanks for joining us

today. Pleasure to be here. Thanks for having me. So before we get into Scale and how it works and when it's used for, let's first get a little bit of your background. So how did you become interested in crypto? I've been working in Silicon Valley at tech startups for about 15 years. So my first company was a company called Good Technology. It was a mobile device management. management, mobile application enablement, and essentially mobile cryptography, mobile security company. So almost every Fortune 500 or Fortune 1,000 company used it and learned about security through that process. But then, you know, had been working in tech thereafter, worked in machine

learning and analytics, actually launched a digital currency platform in 2008, where you could bid on resources internally with this fake currency. And it used game theory. and supply demand curves to really help balance resource allocation. So NASA, for example, could use it for wind tunnel or supercomputer allocation or getting foreign nationals on base or for legal resources for big, you know, global 1,000 companies that have shortages there. But got interested in currencies and incentive alignment through that process. And, you know, then ended up after that building a company that was almost everybody who's

received a pharmaceutical prescription in the U.S., Japan, China, Europe, has in some way been touched by the analytics system I built called Octana with some other amazing people. And what it does is it pulls in data from hundreds and hundreds of sources and it helps get health care information to physicians to help get prescriptions out there. So I had a lot of experience building deep tech. And 2011, you know, had been living in Palo Alto just before then. I was living in the city. And I think the Bitcoin white paper was popping around everywhere. If you knew people who were tech savvy and into new cutting edge stuff. But it wasn't until 2013 that I started really getting more engaged.

And like a lot of people, it was purely with Bitcoin. And then when I, you know, I went kind of pretty deep there, but always from the sidelines as I had a full-time, full-time job at a traditional tech company. But then it was 2016, 2017 really got into Ethereum. And then I decided in 2017, I was starting another company and I was looking again at doing something in machine learning and SaaS or software as a service. And, you know, then just realized I was spending. I was working out of the Saster office, working on a SaaS app. And all I would spend 90% of my time reading and learning about crypto.

I say, what am I doing, building something? And I can get in later to all the reasons why I think it's a better idea. But that was really my onset and my start. I'm really interested about this like internal currencies stuff like how did that go? Like what were people, what were some example? What people at NASA actually using this? Or like who were some of the people using it? What did like, what was their experience of like using market account?

Like, you know, traditionally there's a whole idea of like, you know, you have the market and then you have the firm. But it's like, you know, you're trying to add like market dynamics into the firm. So how did that go? Exactly. You know what? It started off really well. well like a lot of startups do. NASA was to be the first to use it.

And they had issues around, you know, back then, super compute power was not like I couldn't just connect into the cloud. It was they had huge super compute resources on base that people who fought for them. They had a wind tunnel. People would fight for. They had, you know, just if you wanted to get somebody, my co-founder was from Australia. And we couldn't even get them on the base half the time. And we were basically, we were incubated there, you know, working out of, out of an office.

And so they, you know, had a really in the Ames office, a very cutting edge group that got it. Other places, like we were talking to like Intuit and Thompson Reuters had legal issues and legal resourcing issues. And they also got it. Sales teams understood it about like using it to better markup sales territory alignment. But people thought we were crazy. It's 2008. And they're like, you're bringing a digital currency in here.

And, you know, and you expect me to people to pay for things effectively. What if they just spend all the money? Am I not going to give them more money to get more resources? I was like, yeah. Yeah, like, or you could set it up, you know, so every month. And if they burn it, they're going to have to wait the next month. They'll get smarter. But, you know, it was, it started off really well.

Then in 2008, the, you know, the financial crisis hit. And we went from having a pipeline of like 10 customers ready to buy this to people saying, you guys are nuts. You better do something. We're ready to buy immediately. And so we pivoted into, you know, There was a lot of machine learning and analytics going in to help guide the economic engine. And that's how we ended up building Octana, which is, you know, the pharmaceutical technology product used by almost every single pharmaceutical company in the world.

Yeah, because I feel like I've read about this, the internal currency stuff before. And I never realized it was you. I think maybe I, I think maybe Mark Miller might have been the one who was telling me about it. Because, you know, he's really interested in this whole idea of like using markets for internal coordination. I think so I think he may have sent me like some article from a couple of years ago about about this. So that's cool to you know, see it's all wrapped around. Yeah, you can Google. I think in Google Scholar, you could find a patent application for incentiline was a company called incentive alignment. And people kept thinking we were invisible line. So that that didn't work well.

But but I hate someone, it's a phenomenal idea that somebody will execute on. And the thing is people, when money's at play and you have to signal appropriately, you know, what happens is everyone says they need twice as much as they need and they need it twice as fast and then they think they'll get what they want. And if you have a currency at play, it smooth things out far more effectively. So let's get into scale. The scale has sort of a unique approach to scaling Ethereum. If we compare it to like some of the, we've had a lot of scaling solutions on the podcast in the last couple of weeks or months. It seems a lot of them are working sort of at the layer two, working on things like roll-ups, et cetera. And scale network has a vastly different approach to scaling Ethereum. And so I wonder, before we get into how it works, can you like describe the scaling problem as you see it? Like, how do you explain to someone like their five?

What is the issue with, you know, scaling in Ethereum? Yeah. So I think of this as an app-specific blockchain problem. And if every application can have their own blockchain and their success is not enhanced or encumbered by someone else's success or failure, you can do a lot more with that. And even if you can use that blockchain to do things like storage or incorporate other functionalities that are configurable to you, you just, we get such better scale from a societal or a industry perspective.

And imagine if like it costs you more to use your Gmail because so many people use Zoom meeting a certain day, right? Or your Gmail was slower. And having app-specific backends, I think is the way of the future where we get to real scaling. So that's what scale tries to do. And yeah, hey, it has nice throughput and other things. But it's not a TPS battle.

It's really about almost a division of compute resourcing and letting people pay for what they want and configure and use it as they want. This quote always kind of stuck with me. when BloxRat was on the podcast, the way that he described it was that scaling is, essentially in blockchain, scaling comes down to being a networking problem. If you break things down, essentially, like you're trying to get transactions to other nodes as fast as possible in order for those nodes to be able to validate them. And at some point, they're like bottlenecks with that.

And, you know, describing the scaling problem as an application problem, you know, It's sort of like a layer of abstraction, a layer of abstraction on top. But it's a way that at least those of us who are like sort of in the ecosystem and using applications, it's a more tangible way, I think, to like looking at the scaling problem. Yeah. And, you know, one one other, I guess example I'd pull up here is like, so that goes back to this networking, resourcing issue and getting data to nodes is let's say we had 100 nodes in the network. And there are 10 applications that want to use this. And there's no way all 10 of them can use them at peak times in any meaningful manner that is cost effective. So we said, hey, well, let's give each application 10 nodes to work with.

And then we fixed the issue, but we've created another issue in that the collusion element is far easier, right? If you can get 10 nodes to collude and then we lose a lot of the power of our blockchain, right? And so the way we look to solve that or the scale network looks to solve that is it takes this big, broad group of nodes and it's able to randomly assign them to the applications and rotate them. Okay. So that way, the networking problem is still only in a subset. If there were 100 nodes and each one at 10, you just need to network and 10 nodes need to come to agreement or two thirds of 10 nodes.

And we've also cut down the weight and bloat. And someone's using the blockchain a lot and filling it up. Well, they're going to just only pay for within the 10 nodes they use. And they might have to keep buying more resourcing to go behind those 10 nodes. and my 10 nodes, I only use a little bit. So I'm just getting a small fraction and I'm just going to pay a little bit. And I'm not impacted by the other application at all. But I'm at risk if my nodes are fixed, if they can understand they're all working together,

if there's not an incentive component to stop them from colluding. And if there's not a good way to randomly and securely assign the resources or the notes. How does this fit in to say, just for context for our listeners to understand, how does this fit into, say, the Cosmos vision, where effectively Cosmos, you know, breaks things down into application-specific blockchains and allows for every network to have their own validator set

and, you know, scale at the application layer. What does scale network sort of provide in addition to this compartmentalization of applications? So I first of, I think the Cosmos team has a lot of things right in the design. I think having apps specific blockchains is the right approach. And I think we're seeing other networks and designs start to try to mimic that. And so the way we think about it, though, and I won't compare it to Cosmos. I'll just say specific to Ethereum.

So if you're on Ethereum, if we go back to this, like, and these numbers are not accurate, I'm just using them as representation, 100 nodes, 10 applications, 10 nodes per app. If that were the case, there's an attack vector if you think about, like, who coordinates the nodes to go to which application. And if there's a person, a human in the loop who does that, well, I can just assign. I know this Sunny's Dap has a billion dollars on it. I'm going to try to get all my nodes on Sunny's Dap, and I'm just going to take that money and liquidate it. So that's an attack vector. So what scale does is the Ethereum mainnet is where I'd say a huge chunk of this scale network lives is scale, is scale

lives across Ethereum and the scale nodes. So the Ethereum main net, what it does is it speaks to every node. It understands which nodes are available, which nodes are open. It understands who wants to be placed where. And then it uses smart contracts to do that allocation. And so that's how we assign nodes to operate to different apps. It's the main net. And so in a way, too, there's business synergy because on one hand, a lot of layer two is take money away from the main net because you're not paying for transaction fees only when you come in and out. But what scale does is every time you set the nodes rotate, the main net is paid. And so it's almost like a modern day rev share where, okay, we need to do a node rotation.

Pay the main net. Oh, someone wants to stake on scale. Guess what? You have to pay a main net fee because scale is an ERC 20 token. And guess where that stake lives? The stake lives on the main net. So the main net is used for, I'd say, say the core network administration and network orchestration functions, the Ethereum main

net, and then the network itself and the nodes living in the scale network run by people running scale validators, that's where the actual software that runs a app-specific blockchain lives. Could you like, yeah, to explain that a bit, but like what exactly is the scale nodes and what is the relationship with that to the Ethereum network? So are they sort of doing their staking on the Ethereum network and then they're running a new chain? What is sort of, can you get like an overarching architecture of what the scale network looks like? Yeah, yeah.

So I think a really good place to start is looking at each node. So the node has, every node is all Dockerized. It's all containerized. So what we're looking at is there's a component that's called the node core that all it does is speak to the main net. support core network functions. And it does administration, auditing of other nodes, and orchestration of nodes. And that core of each node speaks back to the main net. And then outside of that, there are 128 subcontainers.

And each one of those could be living on a different blockchain. And so if you're running a scale node, you could have 128 daps using your node. But these containers can be just like containers in modern computing, the dividing lines can be broken down and you can have bigger compute resources. So let's say Sunny's DAP comes to the network and has a lot of throughput and needs a lot of file storage and needs a lot of smart contract execution. He might get a medium node. Instead of getting 1-128 of 16 nodes, he's going to get 1.30 second. Or he says, hey, I need the whole thing. and he just buys all the compute outside and around the node core.

And instead of getting 1-128, he's buying more of the network. And then he gets assigned with other than 16 nodes all do that. And they come together. Sunny pays for them on an annual basis. And that's how the model works. So then it's gasless. So the developer is managing the fee. And then so we have this node architecture.

Each node then speaks to each other and speaks back to the main net. I want to set up a validator node. I stake, and my stake goes to the Ethereum main net, and it knows that I'm running this node, then I have the ability to run this node. But the main net's where the stake runs. Then the network runs, the nodes look at each other and watch each other through the orchestration mechanism or the administration and auditing mechanism. And then they speak back to the main net, and the main net then does calculations and

says, Jack's node gets paid this, Sunny's node gets paid this. and we pay people the net the main net pays the bounty and also pulls in fees for the the chains and inflation and so the main net really is the almost like the financial and operations arm of the network but there's no humans behind it it's smart contracts am i understanding this correctly that the scale nodes are are ethereum node you're trying to create a network where existing Ethereum nodes also carry the scale infrastructure in addition to their existing Ethereum node? Or are they like separate entities, like separate? Yeah. So that's a really great clarifying question. So the scale nodes and are separate. They run scale. They run scale on them. But each, what they run is a really fast C++ Ethereum. And so you're getting EVM on each of the nodes and you're getting all the functionality of Ethereum.

so that there's complete interoperability. We talk about losing these like building blocks of composability. And so the goal is that you don't lose any of that when you're in each scale node. But these nodes can't function without the main net. They can't, they don't know where to work. They don't know how to work. They can't get paid to work. But when they, when you as a DAP, I come access my blockchain, my, I run just on the scale network.

Now I pay the main net to give me access to the scale network because I'm paying. paying the scale manager, the smart contract system on Ethereum. So what we've done is we thought to ourselves when we were when we were doing this, Stan had our CTO had five different DAP ideas. He was like kind of working on it. Like, I'm going to do this. I'm going to do this. I'm going to do this.

And I was working on a few different DAP ideas also because I mean, it just was so clear to me all of the business, all the areas you could get a business up and running. And Stan then said, I said, Stan, why do you think you can do five different daps? He's like, oh, look at the architecture I've designed. I'm going to do this. I'm going to do this.

And both of us come from like enterprise software, middleware. And he comes, has a whole background of networking and cryptography and really infrastructure type products. And we're like, well, let's just, this is perfect to be able to license to other people through this model that works with the Ethereum main net. Instead of us trying to build five different daps, let's help other DAP developers with the infrastructure we've built and designed for ourselves. So let me maybe try to rephrase. how I see this. So the existing Ethereum network has, you know, X number of nodes. Scale nodes are effectively Ethereum nodes that have additional software that sort of have like this layer on top of the Ethereum node that allows them to execute computations for smart contracts. and as a DAP, you relegate the compute power for your DAP to a subset of scale nodes

and leverage the scale network's ability to compute this and have a high availability, high throughput. And then so the proofs get sent back down to the Ethereum network. Is that a good way to look at it? Yeah. No, so you know what? Let me, I'll tweak it a little. more, I think it'll make it more clear. There's two very separate networks. One network is the Ethereum network comprised of Ethereum nodes. There's an entirely separate network called the

scale network comprised of scale nodes. Okay. Now, the scale network can only function with the Ethereum network because all of the where nodes work and who they work for and payment and security is baked back into the other network, the Ethereum network. Now, in the scale network, as a DAP developer, I can buy or rent subcomponents of the scale network that get randomly assigned to me and rotated and switched. And what I get, I have a different endpoint. You know, just like, you know, you've got mainnet or Covon or Robston or whatever. I pick my scale, no, my scale chain, we call them scale chains, has its own endpoint, its own RPC port, IP address, and that's my blockchain. And it runs really Ethereum software that's been tweaked and souped up and

different ways so that it's fast and it has a different consensus in it. But that scale chain then is mine for my DAP, but I connect it to Ethereum because when my users come, and then it just operates really as a side chain, but it's not a side chain because side chains have, you know, I think a lot of security issues because of the way that they're structured and assigned and there's not this big pool of random selection and rotation. It's really like a a shard a side shard no just kidding um no but i mean i was going to ask like what you're describing actually does sound very similar to like the eth 2.0 sharding right where like essentially east 2.0 sharding seems to be almost exactly what you describe but then like using this like

eth two beacon chain as what you guys are using the current ethereum chain for so what would be some of like the main differences between the sharding work that's being done by like the 2.0 development team versus what you guys have built here. Yeah. The main difference is that it's it's app specific. So my application gets its own blockchain and then it's faster. I mean, you can do 2000 transactions per second. You can do file storage within the chain. You could incorporate machine learning models to like look at Oracle inputs to determine whether or not smart contracts get approved. There's a lot of things you can do in it. You can buy, you know, just a little bit.

You can buy a lot. And then on the E2 shard, you're sharing that shard, right, with a lot of other applications. So we also designed this to interact with the E2 shards. And so we're excited for when that happens. And we're going to have a lot of work, I'm guessing, to bring the scale contracts, the smart contracts from scale over to E2. and everything transitions. But yeah, you know what?

A lot of people are quick to say, oh, this is a side chain, side chains aren't secure, but we think of it more. Maybe side shard is a good way to describe it. It's a sharding mechanism. And if you look at the validators who run scale, who've signed up, I mean, 95% of them will probably overlap

with people who run E2. And like one of our other bets back in 2017, we started working on this was, we thought the validator, market, a community was going to flourish and grow, and there'd be a lot of incredibly successful business operations where even though it's an open network with anonymity, it's reputation and business are a component of getting delegation, right? And I think that's really come together and it's good for you too. And I think it can support any other proof of stake network like

scale and other other networks. So what about then comparing it to Pocodot? than in that case where, you know, like, yeah, like you said, ETH2, it's, you know, you have many things running on the same shard. But in Pocodot, like, they also have sort of this more application-specific notion of sharding. Would it be sort of similar to that? But then, like, using Ethereum as the relay chain or what would be some of the differences there? And you know what? I won't get into all the nuances, but I think there's definitely like pricing differences and the smallest DAP in the world with one person in a garage can afford to run a small scale chain. So could

a huge enterprise could buy a large scale chain. And so I think there's a lot of more flexibility and fungibility and sizing options. And then there'll also be a privacy option so you can make all transactions private in the scale chain. But the big difference is like scale, the revenue model and the security model is built also into the Ethereum main net. And it's like two lines of code, connect to scale. And when you pay the scale network, you're going to be, you know, at least 20 to 30% of your payments in aggregate are going to go back to the Ethereum main net because you need to pay for your note assignment. You know, there's rotation that happens in the network. People that there's just so many functions.

It's this weird kind of decentralized rev share. You know, like Salesforce.com, use force.com as an app. You pay 15% of your revenue back to Salesforce because you're using force.com. And the scale network itself has this revshare built. in with Ethereum because Ethereum does the work of securing the stake, of issuing the payments, of managing orchestration of the scale network. It is, the scale network can't function without the Ethereum network. Does that make sense?

Yeah. I mean, it seems that you need some chain to exist that, like, does the coordination of validators and whatnot and like shuffling and, like, shuffling, etc. And I guess the question is, why does that have to be the Ethereum chain? When, like, you know, it seems Ethereum chain is actually a relatively expensive place to do this. Where comparing it to Pocodot, for example, PocaDot says like, hey, let's just make, or even ETH 2.0, they're like, oh, let's just make this, like, dummy chain called the Beacon Chain. Or in Pocodot's case, it's the relay chain where it's like, you know, why not use an application-specific blockchain to do all the shuffling and coordination as well? Yeah, you know, and I'll, hey, it is expensive. So if you set up a scale chain, you're going to pay like maybe in today's gas fees like $400ish to set your chain up because you have to pay those gas fees. So a user staking might have to pay $10 worth of gas. And these numbers are always subject to change because there's optimization happening on the scale side and, you know, gas fees as we know change. So so why why Ethereum? The reason.

why is the most critical security elements of note assignment and staking of the network and are, you know, it's like, hey, it costs a lot of money, but Ethereum's the best place to go, we think, for those services for the scale network. The other piece is the network's designed to support Ethereum developers, you know, so it's also like being part of this ecosystem. So I think, you know, you get confidence from the developer that, oh, you're using this chain and I am all about Ethereum, I build on Ethereum. So I think we probably have way less conversion and less of a pipeline and less DAPs excited to use it if it were somewhere else because we target the Ethereum ecosystem. We support the Ethereum ecosystem from a developer perspective.

One last piece is it was so much easy. Well, scale was not easy to build. Okay. It was really difficult, but we, there are a lot of things we just didn't have to worry about. It's just interoperable with Ethereum. There's so many things that just out of the, out of the box, we were able to use to get the network up and running, and people that use scale can use other pieces too out of the box because it's interoperable. So that even helped us from our own developer perspective of being able to leverage everything in the ecosystem. So you mentioned the scale manager briefly. Could you describe in detail what is the purpose of the scale manager and how it interacts with all the nodes and the validators?

So the scale manager is a massive set of smart contracts. I think when we deployed main net, it was, I think it was like 16,000 USD of gas fees to deploy it. And it was pretty heavy. So it's a really, really large set of smart contracts that do a lot of different things. One is the scale tokens and ERC 777 token that help that, you know, is the economic driver within the network. for behavior and incentives and rewards. The other piece here is, you know, so you stake, if you're staking in the network, that goes into Scale Manager.

If you're a developer and you want to scale chain within Scale Manager is where we're going to is where the network looks at resourcing and it runs a kind of BLS signature Randau thing to do entropy. So all the nodes together work together with the Scale Manager, the scale nodes, work with the scale manager to come up with random numbers. and then there's also a component that does, that gives bounties. So it takes in the fees. So if I pay for a scale chain, I pay to the scale manager, pay in scale tokens.

That goes in. And if I buy a 12 month contract, one 12th of that every month goes into this bounty pool. And then this bounty pool then also has, there's an inflationary piece. So every month, a certain amount of scales inflated. And the inflation for that month and all the fees combine. and then every node watches every other node and produces a score for other nodes and there's all this kind of washing out and and cleansing and things that happen to ensure that we're getting the right scores and it just finds a middle ground and and it's very binary it's like did you meet the objectives or not and it's like basically uptime latency and and you know performance functionality elements and every node that met that then gets a cut in that stake every pool every month. And every month, those awards are sent out to the network through the skill manager. And then it goes to the to each validator.

The validator then on chain has a mechanism to say, here's my return. I'm taking zero or one or 10% or whatever. And it goes to their wallet. And the other piece of the return goes to the delegators wallet. And all these, you know, all of these wallets and all of the scale token, right, is on the Ethereum main net. So it's also included in the broader scale manager. And so that's why it's called skill manager.

It just manages the network. And the code's all live on the mainnet. If anybody wants to go, like, check out the GitHub, check out the contract addresses. So what would be the process of, let's say, I wanted to start running a scaled node? So are there, how do I find out sort of what are minimum system resources needed? And can you, like, walk me through what are the steps I would do to, from today, I wake up to run a scale node to be validating on a couple of scale chains. Yeah, so you could go to scale.

Chat to the Discord. There's a community there and they could guide you. You can also just go to the developer documentation. There's a, I think a pretty robust documentation on scale. Dot network, scale with a K. You could find information there. And then you can go to the GitHub, all the codes is open and public. The first version, the very first launch, is limited just to nodes that ran in the test net.

And there's a compliance component to which we don't control that, you know, there's a proof of stake launch that's happening. And meaning like there'll be an auction and people come buy a token and then they have to stake it. Then the tokens lock for 90 days. There's no trading. and there has to be a fixed number of validators because you have to meet a minimum threshold and these people are buying and staking. And if they buy on the auction,

they stake to a note that doesn't have enough in it, then frankly, they don't get any return for 90 days. And that's not the experience we want. So after that 90th day, anybody can show up, do the CLI and get your note up and running. You have to have enough delegation to meet the minimum stake requirements. requirement per node and then you join the network.

But what about like from system resources requirements? Like how do I know, is there a minimum that if I want to run a scale note, I have to have at least this much compute, this much storage? Like how does that work? Yeah, exactly. So it that is all listed to in the documentation. And it's, you know, it's like you can run, if you're running this in the cloud, it's like a couple hundred bucks a month to run. run a scale node, so it's not a small machine. The storage piece is a really interesting question.

We, you know, the core team is still at a place where, you know, it's open source community involvement here, but pretty soon the community has to all, you know, if things are going to change, it goes through a very different process. And one of the top, I guess the most difficult recent decisions was what should the amount of storage be? because the more storage that's there is, and if you're running in bare metal, it's like hardly a difference in cost. But if you're running in the cloud, you know, to go to like, you know, 10 terabytes instead of four is dramatically different.

And if you're running 10 scale nodes, that's huge operational impact to, you know, change for paying a cloud provider. We're hoping that the economics drive people from running nodes once they see that this is something repeatable and sustainable, that they'll get off. of cloud and move into more bare metal setups and co-location setups, but the returns just a lot better

from that perspective. So, yeah, that was a tough decision because your block storage is impacted. The file storage component, you could run, you know, a whole decentralized application using file storage. These things are kind of in contrast to validate a return. And obviously, from the DAP side, we want to give them as much as possible. but the validators have to worry about ROI. So it's very clearly, we could just say,

oh, guess what? We're going to pass that fee. We're going to pass it over to DAPs. Fees go up. But there's just, we haven't gotten to the point where the network's just getting up and running, right? So we need to make sure we create like a positive network effect. So I think over time, the community will be able to vote and say, hey, let's increase fees and increase storage.

And then it's a win-win. But we want to, I think, you know, that will happen later. So those specs, I think you could. Yeah, you can just go to the Discord and to the developer documentation and find that pretty easily. In terms of storage, is it possible for or is it foreseeable for scale to perhaps also leverage some of the storage networks, decentralized storage networks which exist? And there are many sort of like as an endpoint where like the nodes themselves could leverage external decentralized storage solutions in addition to or instead of, you know, bare metal storage or. having their own kind of like local storage. Yeah, actually that is another interesting topic.

So part of what we want to do is so let's say if you get to the point where you're doing millions of transactions per day, you're going to have a lot of bloat eventually in your scale chain. And over at a certain point in time, you may fill that up. And it could be a year. It could be six months. It could be five years depending on how much you use. But if you're using huge, if you have a lot.

huge throughput that needs to be stored, then what happens is the network, the system's set to prune. So just start pruning old data. Some people want to keep that forever. So we actually have a GitHub grant live with RWeave. And we're doing this in conjunction with RWeave, just have someone go and build this connection between scale and RWeave. And then it just automatically passes your data to the RWeave network. And you can store it forever there. And it's, and it's decentralized, trustless permanent. So that's one piece. And we were going to build it.

And RWeb was going to build together. We said, hey, let's let the community build this. Let's get, make sure this is really open source. And obviously you could connect to an Amazon server and store your data as well. But that doesn't meet the requirements for a lot of decentralized applications. Yeah. That's really cool. You know, we had RWeave on a little while back.

And, you know, they're building this perma web. And, you know, there's other projects out there like SIA for, example. They've got a slightly different vision. For them, it's more like decentralized cloud storage, like a decentralized drop box. And it feels to me like one obvious use case for all of these systems is just offloading kind of like some some Ethereum bloat, you know, any blockchain, basically. And like let's just like reduce the size of those blockchains and like put the first five years or the first 10 years and just offload them on to these decentralized cloud storage solutions. and to leverage them also for like

things like archival storage for specific applications, I think it's kind of interesting. Yeah, you know, it's just another like kind of like wake up call to all of us. You know, we get so deep into the current present state that like it's nice sometimes like, you know what? We're really early here. And like why do we do things we do?

Like sometimes it's like religion or a best practice of the moment. And then you kind of pick your head. Like, you know, why if it goes to our weave and it's there forever, then who cares if it gets pruned from the scale chain or it goes somewhere else, right? It's, I think we're going to have different instead of layers. We're going to have different, you know, there'll be a place where action happens, execution happens. There's a place where maybe storage might happen. There's a place where, you know, there'll be different zones and areas as opposed to just layers, I think.

And it'll look more like an enterprise software map, ecosystem map, compared to, like, like this kind of very basic protocol stacking. And it's just, we're just young in the industry, right? This stuff's just just getting started. Could you walk us through then the other side of, you know, let's say I wanted to go ahead and create a DAP on the scale network. What would be the process of me doing that? How do I sort of know what sort of resources my DAP needs?

How do I know whether I need a one 16th or one quarter of a node? How do I know any of? Or how do I even tell how many validators I want? Yeah. So the first version of the main net just for, you know, just simplicity is better from a security and an execution perspective. So you have three options right now. You can have a small, a medium, or a large chain.

Very, very. And, and the costs are dramatically different for those. And then in terms of number of nodes, there's just a fixed set of number of nodes. So in the future, you could get, you might want to get 64 nodes all running the smallest component, or you're going to get, you know, right now it's just, there's only 16 node groups and you can run one of the three sizes.

So what you do is pretty clear, like you have to think, like, do I care about throughput and like transactions per second? Do I care about ability to store things due to decentralized storage? What do I care about? So you think about what you care about, then you'd say, you know, I think the small chain can do 20 transactions per second max. And it has less storage. The medium chain is something like 100 transactions per second.

And 2,000 transactions per second roughly is a large chain. And there's just dramatically more storage too. And so you kind of see where you fit. And then they're called elastic side chains because of one, how things are configured and pulled together. But also because they're elastic, I could be on a small chain and say, you know, I'm going to upgrade. And then you just have to light up a medium chain and then you move everything over. and there's a transition process that's not as seamless as in the Web 2 world, but it's doable. And you can just move up the ladder as your throughput changes.

It's not as elastic as EC2, but it's more elastic than what we have today. So then what you do is you just build something for Ethereum. And two lines of code, you deploy to your scale endpoint, just as you're deploying to, you know, a different, right now you'd be on a test net and then push then to main net or you'd go to another test net. just go to a scale chain and that's your scale chain, then you're connected, but interchain messaging is a little more involved. And that's where there's more, you know, where BLS threshold signatures are being used to sign off on amounts that to be transferred and going to like a proxy contract and then going to the main net. And what happens is as you come over, you end up creating this element where you freeze assets on the main net and then clones or a rap version is created on

the scale chain. Those are used and then when the end user wants to pull out, the Web 3 connection just points back to the scale chain and it says, hey, take money out. It runs consensus. BLS is used to then message that in a lightweight manner back to the main net. And then those assets that are cloned burn essentially and then they unlock on the main net and they go back to the user. Can I transfer any asset? Like can I do any ERC 20 or 721 or? Right now, there's just.

support for ERC 20, 721, die. And there will be when the network goes to phase two launch. And so all this is, that's what we've built. So your standard stuff you're using on Ethereum will all work. And eventually, you know, the goal is to make that even more robust to be able to take in a cloned or wrapped Bitcoin and run it inside of Ethereum applications. And so, and part of this too, like I, I, I've, I've, done a lot of software startups when you're in the space we're in, you think you're going to do

all this stuff someday. And what happens is you end up getting pushed more and more to your core strengths and the ecosystem develops and you know, you start using partnerships to do other things. So maybe even someday, like we have entertained messaging, but there may be some entertained messaging agent or tool that is the best or instead of us creating this BLS or this threshold signature bridge to get Bitcoin in as, you know, developers use something else. And we just keep focusing or the core team here keeps focusing on the piece that's really, you know, nuanced and specific to what our core strengths are. So it'll be, you know, we'll see. We'll see where our roadmap goes over time.

So when we like do these like resource constraints, like, okay, the small, medium, large, how does that like, what is the literal instantiation of that? Is that like, so these are all running EVM chains, right? and so would it be that like it changes the gas limit per block so is that is that where the actual where it's actually changing like so you know a small chain gives me two million gas per block while a medium chain will give me five million gas per block or how does that work yeah you know good question so it's it's literally the amount of compute resourcing you have and if you're using more than you have it just frankly gets gated it just gets it just gets uh it just gets throttled down. So, so what happens is, is you, these chains, you could think of them as little

building blocks, right? And there's 128 of these and in each node. And if I run a small chain, the network devotes these 16 containers to me across 16 nodes that are the smallest container sizing. And so I get, and I just have that amount of resourcing. And then if I'm pushing more through than what I've, what I've licensed from the network, I just, you know, It's just physics. I'm trying to push more in and I don't have enough space for it. How does like a developer get like a good sense of, you know, so, so if I built my own EVA, I launched my own EVM on a scale chain, I get a set what the gas limit is then. How do I get a good sense of like what is the relationship between gas versus gas limits versus like compute resources

available to me? Yeah. So what you do is there's actually, actually a fake gas that you assign within your your application that users use that only serves the purpose of preventing Dawson, just so you make sure no one's spamming the network. And if I'm spamming the network, my, you know, me as an end user where I'm connecting, I just run out. And then, you know, I get a certain amount back the next day. So that's, it's not a cost thing. It's a resourcing thing you can use.

And you can just have this faucet. You keep, you know, getting it just, it's automated. gives people gas to use, okay? So that's how gas is used. The cost element is there's no, it's just gas, it's just, there's no fee. You can use it as much as you want as your users can.

And you're just paying for the amount. And if you're saying, wow, we're like getting really jammed up and things are slow because we have more, more pushing through than we have reserved, then you move up to a bigger, a bigger set. And so then you would change to a medium chain and a large chain.

And then I think, you know, then you could even say, oh, we want more for storage, you could light up a small chain and that be used for storage and then use something else just for smart contract execution. Or maybe use a large chain for storage because you have a lot of things you're storing because you're running an entire decentralized application end to end, and you just have transactions going on a small chain or something. And so you can use these different chains and set them up to your needs and requirements.

Yeah, so the gas, again, I think circling back to your original question, you could think of the gating force here is the amount of containers you have the gas is a construct that you issue as a developer just to prevent dossing so one of the oddities of the e vm is it treat storage and compute as like fungible resources with each other where like they're both measured in this unit called gas and it kind of like pegs their prices against each other but It seems that might not always be the best approach. Because, for example, in a scale chain, maybe I want to give people a lot of compute capability, but not a lot of storage capability. Is there a way to sort of create two notion, like separate out storage gas from compute gas? Yeah, you know what? So right now it's fixed.

It's one of the things we want to make configurable in the future. So right now, you, I think, of the amount, there's only, there's a certain amount. that frankly can be of storage just within your containers. And right now, I think 20% goes to transaction storage and storing transactions and something like 60% is going towards file storage. And then the remainder is going towards storage requirements just around the network. And so what we want to do is someone might say, hey, I have no files I'm storing. I have nothing.

I don't need file storage. And I want that to be zero. And I want to open up the rest. I want to have three times the amount of, I guess, transaction storage capacity. And so right now it's fixed. It's hard-coded. Eventually, you could see this. Like, I don't know, there's probably a lot of people here who are familiar with Enterprise and SaaS.

And SaaS is all about, like, understanding use cases and making things. So off the shelf, people, there's enough people that say, hey, I want this. They can click a few buttons and get things like baked into the system, configuration options, ready for them. And it's not, you know, you don't want people in there customizing each scale chain. There's one set of software that runs across the network. And right now we're, we're very junior varsity and 101 in the setup. There's like three options. But it's all done, you know, for good reasons around security and performance.

And over time, hopefully that will evolve. So if each scale chain is just a plain old EVM, what's to prevent someone else from, like, you know, just parasiting my scale chain? And so I, you know, I as a developer, I paid for this, like, large scale chain. And what's to prevent some other person just deploying their own contract on there and, like, you know, just like siphon and like, you know, making use of the fact that I already paid for all the compute and everything up front and then just using it for their own use case? Yeah. So, so my understanding is so they're nuanced things built into it so that only the developer has access. So there's just a, and I don't know offhand the exact mechanism used, but that was built in. So if someone has access to all of your systems, then yeah, they can go access your chain.

So does that mean like users can't, users wouldn't be able to like deploy their own smart contracts? No. So just the developer is able to deploy the smart contracts to their ecosystem and has control over it. But what if I want to like as a user, what if I. want to deploy a multi-sig contract or an Argent smart wallet contract or something like that, like more of a user-side contract. How would I do that if contract deployment is like limited? Yeah. So the way it's been designed now is the developer is essentially like the owner of their domain as if you owned a backend database. And so I don't have the exact details on how they can

open up configurability. I'm sure you could open up anything, but the goal is to make it so the design spec is I have my back end here. I pay for or my group or my community pays for collectively. And certain people have these controls. Other people have these. And you can just open it up, let anybody do anything to it. And somebody might come and do exactly what you talked about. Or you keep components of it that are less publicly available and just, you know, the businesses the applications, the groups, communities, projects that are using it, then open up only what they need to. But it's just like, you know, we, I think for application-specific blockchains,

you need to have similar security requirements that you would for a normal application. Like, can somebody come leach off of my Amazon EC2 instance? No, right? But if I want end users to have interoperability and to come build things and connect or, you know, pull things from an API, then I have to build those connections. So it's a good question. I think, yeah, maybe we'll write another, we've got a lot of content. Maybe we'll write about that and we'll write up an overview of how the network's been designed

to give configurable security to application developers. So these connections essentially now that people are building, you know, and sometimes people start building these connections for the applications they need. If we come back to this kind of, you know, like Web2 software and apps, like Web2 software and or Web 2 development platform analogy, do you foresee kind of stores where people would sell access to these types of connectors? Like you would, like on a Shopify app store or something like that, right? Like you want this extension?

Well, you got to pay for it or anything if you're not looking to build it yourself. Yeah. So it's an open, it's a great question. I think we're talking about cool future things too that could happen. So if you think about it, what we have is just a network of blockchains. that's run and driven and orchestrated by the Ethereum Mainnet and foundationally secured by the Ethereum Mainnet. And these blockchains, you know, 1,000 nodes could run 8,000 small blockchains.

So there's going to be a lot of these. There's going to be a lot of people that maybe will license them and then package them with other things and then sell them almost in a red hat type manner or, you know, open source business model where you get things configured and you pull in the wallet, you pull in these these components and you ensure that there's security auditing. And so we have one one person who's working on building this now. So he can take his prepackaged offering to game developers and Web 3 developer, or Web 2 developers that want to use blockchain and in a way, Shopify the Ethereum experience for them.

They pay in Fiat. He does conversion to make the, you know, in an automated way to license the scale, to connect to a Portis or Taurus or Fort Maddox or Bitsky and there's things that then proof and check the smart contract language to make sure that they're not losing money. And I think things like that are amazing that give more accessibility. It can take two normal developer, the Normie world developers who aren't here living in, you know, blockchain land. And so I think cool stuff like that will happen, I hope.

But we're just trying to stay at the infrastructure level to make sure that we can give people those options without exposing attack vectors. Right. Interesting. Could you talk a bit about like how does some of the security properties of this work, especially when it comes to things like fraud proofs or data availability? How do I, you know, let's say I happened to, you know, through this random sortition, I did somehow happen to end up with a set of 16 validators from my chain that was corrupt.

And what is my recourse now? Or what about the data ability side where, you know, I had a bunch of storage and now suddenly the validators refused to serve the data. So one thing to note is there, this is, it's relying on Byzantine fault tolerant performance. So if two thirds of my node operators go bad, that's a real issue. And that's why we take the randomness, rotation, the seeding of the network, the incentives of, you know, you. validators lose so they lose their whole stake if they maliciously collude and and steal money. So this is also folds into the what is layer two question, right? Because I think a lot of people are, and layer two used to just be you could connect Bitcoin to Ethereum and that I have a layer two because, you know, this one is where this is one blockchain.

There's another one. This is the primary one. And I'm creating an application environment. And then, you know, there's obviously been a sect of researchers who are, you know, we're working on plasma and now roll-ups and ZK and other techniques to make sure that there's no consensus or nothing can happen on the second layer that the first layer doesn't agree on. So you make sure that Ethereum is your main place for security. And so then you have a central node operator that performs different functions. you make sure there's data availability. You make sure you have timeouts on the user side so they can't get liquidity for a certain period of time in case that central operator goes bad.

And scale doesn't work that way. Scale is another network. You're trusting another network. Imagine you connected to Cosmos and the Cosmos validators went bad and stole the money. And before it went back to or the Ethereum main net, if you were to set up a, you know, you're just trusting that set of validators. So what so things that we can do, One, you can limit the quantity of that someone could pull out every day.

So you can basically make sure there's not a mass exit per per like to steal money. There's things like that you can do. There's other things that the system takes a snapshot every, I think it's right now it's every 12 hours, but you could make it do it every six, every six minutes or every, you know, 60 minutes, whatever. And it snapshots your state. And if you do have malicious validators, the network or ones that stall, then the network self-heels. It pulls them out. And then it puts in new nodes.

And so in the short term that, so that's, it's one is set up. Someone just quits running their node. It gets removed and it injects another one. And in any given time, you could stop it and you have your latest state. So those are things that you, and, you know, you could just be in a point where. You have two thirds of them and they refuse to work. And then you're, you know, there's going to be like an intervention, I think, a human in the loop intervention. But again, it's just about resetting that snapshot and rotation mechanism that then re-rotates new nodes into the chain.

And, you know, the, the amazing thing about blockchains is that there's like no foolproof thing. If like everyone's bad, it's really hard to get blockchains to work. I've heard some people say like, oh, even if everyone's bad, as long you have one good actor. And it's like, well, blockchains really are set up to have the right incentive structures to make sure that the majority is pushing through the right actions. And so I think a lot of these fears are a little bit overstated because of the maturation in the validator market and kind of the reputation element, even though they're not proof of authority in to run. And then, you know, having the right types of incentive structures. It's just getting a two-thirds attack. If the network were ever in that state, I think it'd be in a really, really bad place.

And you probably wouldn't have quality depth running on it anyways if it were susceptible, that sort of thing. Let's take a bit of a step back and talk about the business here. And also there's this, we haven't addressed the foundation. So the Node Foundation or N-O-D-E Foundation, I don't know if that stands for something. Can you talk about that, describe what that is and what it's, role is in this broader vision? I think foundations for everybody are great things and annoying things because we all just want to have like a decentralized network that runs that we can support. But you do, if you do have a grant, a grant program you want to run, if you do want to pay

certain groups to focus and work on the platform, you do need to have a kind of entity that helps support, make that happen. And so the, the, the, the, Node Foundation and Onchstalt are set up in Lichtenstein, and they're really just there to support operations. So Scale Labs is a client is, I guess, a vendor supporting the foundation. And we have a contract and we get paid a certain amount every year. And it's really just comes down to cost. And it's just basic startup salaries and, you know, marketing spend and money to, you know, spend on hackathons. And it's community money that was raised through staffs. that then got all passed to the foundation.

And then there'll be a public sale, that money goes to the foundation. And then other vendors will come on board and support the network. And really, we're just trying to follow best practices we've seen through Cosmos and Ethereum and other, I think, foundational structures that, you know, you need to have some element of humans managing money that's compliant with the securities laws and laws that pertain to, responsibility and liability for the network. But at the same time, you have to make sure that whatever the entity is, it doesn't have enough power to have any negative impact on the network itself. So there's the foundation and then the company is a U.S. company, I suppose?

Well, so the company is just like Scale Labs, Inc. We were, Stan and I said, hey, let's go build this And let's do an open source decentralized thing. And we had a corporation. And I guess SAFs were used to get early supporters involved. And then at a certain point, we're like, okay, we don't, this is not the right structure to have a corporation of any control or power over the money. And so this entity in Lichtenstein was set up and the money was passed to the entity in Lichtenstein and the SAFs.

And then that entity is responsible. The main thing is to launch the network. and to manage the foundation grants. So there'll be grants that go to DAP developers who build on scale to not send to liquidate, but for them to be able to fund their chains for a certain period of time. There's an incentivized test nets that happen. They get paid out through that group. They're like the get coin bounty with Rweave, right?

Things like that need to come from someone and it's not right for them to come from a corporation. And so that's why the foundation. exists. And can you talk a little bit about the different phases of the launch? Yeah, so there's three phases. And, you know, this was, it was one of these things I've noticeding a lot of people are doing phases. And for us, it just, and for this group, the community was like, it made more sense. And one thing was we wanted to just get the network up and running and on its feet before live staking happened. And, and so what happened is there on June 30th, phase one launched and everything deployed on the main, net and and there's just it's a kind of idling network where there's no bounty or rewards being given yet

but it's up and now what happens between now and phase two which is on august 31st validators can join and get set up and then once they're set up on September 1st the first epic starts and that's when payment everything gets going so the the people have a runway and then staking all has to happen to before the first. So people that purchase in the activate auction and that have to do proof of use and stake their asset have to stake by September 1st. And same as anybody who had a saft variable. And so we just have this time that's not like, okay, let's do it all in two days or the network's live and have a mad dash and make sure nothing's broken. So that's why phase one exists. And then phase two is really about compliance and health of the network. And so for 90 days, there's no trading.

nothing's liquid and real staking happens and DAPs are then able to come and and participate and start using the network. And then when phase three hits, then it's like any of these networks with a token and having a liquid asset. But we get there and kind of, you know, crawl, walk, run style. So you mentioned the grants program like in these early stages. What do you think that will look like in terms of, you know, the types of things that you're looking for people to build. And so I suppose the company then will be kind of the one sort of giving the grants, or is it, nor is it the foundation? The enstallts, I guess, are Lichtenstein structure.

So it's, it can, the onstall is basically a business that supports the foundation. And so there will be a kind of process and, you know, there'll be a submission to say, hey, like, we want to give way X amount of grants. And maybe scale labs is. hey, can we give away X amount and here's exactly what they'll be used for over the time period. Let's make sure there's transparency. Or maybe someone else will say, hey, we want to get involved here. Can we do a grant program for these people?

And then the enchstalt basically says, okay, great. Someone came to us from South America and wants to, you know, get grants to developers through this mechanism. We'll sign a contract with them and then they can do that. And so it's more about a we don't want to have a huge operational structure going on in the foundation now. or just think the community is too small. And so the enchstal will be responsible for kind of finding groups that can then support growth of the network. What are the types of things that you'd like to see supported in the early days or like with the initial grants? Like what are the types of things that are most needed to be built by the community for like these, you know, ongoing phases to be successful?

Yeah. So the R-Weave integration is a great example. there's a grant that's going out for building an R-Weave connector. Maybe you build a connector to another decentralized storage network. People that want to get involved in interchained messaging. There's grants going there. There's a white hat hack effort going on through Hacker 1 right now that people can look at and get involved in. There will be grants given in the same way Amazon was really successful because they came out and said,

hey, we'll give you X amount of credits for over a period of time to use Amazon. And so they went to promising startups and they gave all these startups, essentially fake money that they could use within Amazon to use cloud credits. And then Google did the same thing. So we have a version we're running where there's a three to six month credit that happens. And I'd say, hey, I'm a developer and I've got a promising team and I'm serious. Then they can apply to be in the skill innovator program and then they get a grant. But that grant then locks into the network.

it doesn't end up on an exchange right away. And once they use it, it actually just goes back to validators and delegators through the ecosystem, I guess, or the financial mechanics that manage fees. So that's another thing. You might say,

hey, I'm working in Berlin. I want to get a grant program going, and we've got, let's get more developers using this, or that would be exciting. And the other piece, too, is just interchain messaging. And I'm sure Sonny,

you know all the challenges of having money go in between networks, Like if anybody wants to take a look at that code, I think that's something we're thinking of putting a grant up to sometimes soon just to get more eyeballs, approaches and efforts. And I could see that being a lot of supported mechanisms to help different assets transfer between scale chains and the Ethereum Mainnet or other places. Okay. So where can people learn more and get involved and perhaps even reach out to get involved with some of these grant programs? Yeah, so please come to the Discord and you can get looped in. So scale dot chat and you can find these links all on the scale website scale. Scale.network. And you can also reach out on Twitter and through the very different people or the scale official Twitter handle. But please come. We're really, you know, we're really part of this Ethereum fabric. And one of the hard things about the quarantine is.

We used to be at a different Ethereum event or hackathon every month around the world. And I think a lot of organic integration and work happened that way. And now we're in a different challenge where no one's traveling and seeing each other. So we have to, I think, be more thoughtful about getting things like this going. Yeah, absolutely. Hopefully at some point we'll be able to go back to Ethereum conferences. But for now, we'll stick to Discord chats. Jack, thanks.

Thanks a lot for joining us today. Yeah, hey, I also want to say, so you were asking me about my kind of onboarding into crypto. So I thought I knew a lot about crypto and blockchain. And I realized I knew pretty much nothing when I first started working in 2017, full time. And one of the main outlets for learning I had was listening to Epicenter. So I think I listened to like, I probably listened to a hundred episodes at least. So it's a pleasure to be here today. And I've always been a big fan.

So thanks for having me. Well, thanks very much. It's very nice. Thanks for joining us. Thanks, guys. It doesn't end here. There's more to this conversation, and you can hear it on Epicenter Premium. As a premium subscriber, you'll get access to a private RSS feed where you can hear the interview debrief and get enhanced features like full episode transcripts and chapters which allow you to easily skip to specific sections of the interview. You'll also get exclusive access to roundtable conversations with Epicenter hosts and bonus content. we put out from time to time. Go to premium.competenter.tv to become a subscriber and support the podcast.