Welcome to epicenter the show which talks about the technology is project that people are driving decentralization and the blockchain revolution. I'm Felix. And I'm here with mayor Roy. Today, we're speaking with Colleen, Myers and ocean keine, worte cofounders of mobile apps. Mobile is building software to enable distributed operation of validator. He's starting on aetherium. Hi, ocean. And hi. Colin and welcome to epicenter. Hey guys, thanks for having us
pledge to be here. Yeah. So both of you actually were in touch for like a long time. You've both been in the space and in staking, especially for a while. So, you know, as is customary on epicenter. We'd love to first, get an introduction to how you, how you got into crypto, and how you got to where you are today? Maybe calling you can even start Yeah, cool. Yeah, thanks, thanks for having us again. I have been watching and observing epicenter for from a distance and always wondered
when we get our shot. So, yeah, happy happy. I finally came. Definitely on the longer end of the spectrum, based on my expectation set. But yeah, happy, we finally made it happen. Yeah. So quick, quick background on me actually. Non-developer by background used to work on Wall Street worked in a variety of different banks.
It's mostly in like credit and debt and got involved with etherium Community 2017. I was living in New York and, you know, lucky for me, there was consensus, and there was Joe Lubin and there was meetups and you know, it was different stuff happening and at this point in my life like 2017, I was trying to spend a lot of time, you know, trying to work at a hedge fund or a private Equity Firm or actually, honestly, just totally lost it still like, what I was supposed to do, and There was
two things going on at that point in time, one of them was we work and the other one was crypto in New York and those were like the two main things that everyone was buzzing about and work worked in trying to get a job there but also spent most of my time on it period 2017. I met Joe living in a Meetup was inspired to quit my job. So I did then I joined consensus in 2018 and I worked there for about three and a half years at consensus, was able to work on a lot of different.
Technologies even like space and blockchain and some crazy stuff like that but primarily focused on staking I started a project called token Foundry which was like an early mover in this space to helping Network's launch and trying to do compliant token launches turned that project into a project called activate which was recently sunset by codify
something. We actually partnered with on course one in the early days and throughout those time periods I spend a lot of Didn't time contributing to eat to was involved in early working groups. After Devcon for, and I primarily at the beginning focused on the economics of E2, they were not very well understood and my job was to help enable the understanding of the economics. For your at-home. Validators for your larger scale, validators, your
exchanges. People like quite basic consensus and these different types of actors. Those initial work streams led to a lot of different enablement projects around the Genesis event. So the majority of my time was spent around the Genesis event and enabling that to take place while it consensus. We built the eats you launch pad, which is so individual place where you're at on validators.
Interact with the deposit contract, spent quite a bit of time with the client teams and help them with user feedback. And ultimately all of these research projects culminated and what today is Is now DBT. 2019, dr. Fights. And curl be started to research group focused on trust minimize staking and Marsh meet and myself, were the first two to come in to help enable that. After it, got completely sucked down the rabbit hole on DBT, thought it was world changing technology.
Three years ago, no one had any idea what we were talking about? It was kind of grossly underfunded as an effort and ultimately the The only way that we found proper funding to turn DBT into a project was by ocean and I both quitting our jobs respectively and going out and, you know, raising capital on our own and finishing the effort and putting the group of people together to make the technology a reality. So, yeah, that's me. Thanks for having me on.
I'm a neat Maxi, loving Cosmos these days though, but yeah, really excited about it. And then yeah, to give my background, I'm a software developer by background and in fact, I'm the fortunate person who's like, second generation internet entrepreneur. My parents have run web companies, most of my life. So yeah, would have grown up around kind of original website, building web design and the like
late 90s early noughties. And so, I kind of sass companies built in the kind of notice and 2010's and out of college. I worked as a consultant and kind of discovered.
Crypto in 2017 and got my first kind of full time role in 2018 when consensus opened an office in Ireland, and I did two years, they're in their tokenization Department, we did some projects, very tokenized Securities for French real estate on maenette back in 2019, before that was prohibitively expensive to do on my net, and I left consensus in March, 20, 20, and I Incorporated myself as a self-employed kind of
contractor. Picked up by black demon to do e to research for them back in 2018, when the originally two specs came out my I wrote an article that was effectively quite critical of them. At the time, it was 1,500 either minimum and Sachin was fairly severe. And I was like really do bees with this was going to be safe or make sense and then yeah, I kind of kept an eye on it. Got involved with block demon building it along and end up
building out their teeth to stack for them. by Genesis and I say shortly after Genesis I was first introduced to the idea of trust was validators by getting an invite to this trust was validated Community Hall that common Ameri running and at the time I was kind of agonizing over having no ability to run a backup validator or do anything when one failed and I was introduced to this technology and it's like, oh it's high availability for validators, is definitely going to be thing
everything in web to does this and I was kind of an immediate convert but yeah I think Colin realize it's not very many other Where yeah, we took me maybe a few more months of kind of being involved. I was trying to make an mft issuance kind of Stack. I did some work trying to issue like rugby video and ft's with some kind of like, famous rugby players that didn't really go to plan.
And then someone once approached me and asked me to make a nearly 20 token for to represent steak, and I kind of counter pitch them and try to make like NF teeth to represent validators. And then, yeah, it, I wasn't Really very good at selling any. This idea had a product but I had no business Acumen and I realized that I wasn't really very correct for the whole CEO
role. So I reached out to one of the only business people I knew in the space, who's Colin because a couple of people have been kind of pushing my me his Direction, and I was talking to about what I was doing. Yeah, she'll be what he was working on and what I wanted to do with oh ball took me a few weeks to get convinced that it was not too hard to attempt. And yeah, I think we kind of
started around April 20-21 together and here we are met. be 2 years later, but more Awesome. Yeah that's a rich history. You both have and thanks for going too deep into it, I think. Yeah, we personally also have worked a little bit on high availability of a validation. So like we're both very excited about this episode so yeah I can to get into it right? So I guess maybe we can start there. We already mentioned DVT a bit. Maybe. Can you explain? You know what is distributed
validator technology? Yeah, cool. I'll give kind of a more macro perspective, is to like the difference between a normal validator, and then, oh, she can get a bit more into like technical architecture and deployment and stuff. So, today, a validator consists of three pizzas. It is a public-private key pair is a machine and it is an agent, an agent. We look at is an individual or an entity.
So it's three things and all of those are super monolithic and that's just The validator stack of today from an Indian perspective, what DBT enables is a more modular validator stack and now what happens post DBT is you have key shares, not just one public-private key pair. You have a collection of key shares as many as you'd like to create based on your trust, you
know, properties. Essentially, the next piece is that those key shares then can go on multiple machines, not just one machine, but multiple machines, and then third, and lastly, this salad Can be run by a group of people or a group of entities. So it takes your modular validator today, super monolithic and it takes it to the more modular version where you can have multiple key
shares. It increases your security, you can have multiple machines and increases your availability and you can have multiple people or entities. Therefore increases kind of your game theory or decreases. The chances of Byzantine behavior for that validator and I'll give it to a sheet and you can go more Linda kind of technical talk. Yeah, I think an epicenter podcast. Maybe one of the only places where I can talk about their like nerdier details of this
rather than the high-level idea. But yeah, I think one of the interesting things about it or what, you know, makes these distributed validators more possible than they might, otherwise be is the cryptography that etherium to, I should probably stop saying the word of to use as proof of stake etherium. And that's the BLS signature scheme. What's so fancy about the BLS signature scheme? Is it's one of the first signal like elliptic curve signature schemes.
Where if you have, you know, independent signatures all for the same. Hash you can actually like add them together in a low trust environment. You don't need the original private key to do so so what happens as Colin alluded to is you know you want to set up a
distributed validator. The first thing you probably do is a distributed key generation unless you want to just spit a normal key locally, but it's better if you kind of do one with the dkg, then at the end of that process, there's you know, let's call it. Or machines to keep it easy and each with the piece of the private key on it and you have a piece of software in the middle of your validator stack between your like consensus client and your validator client and it
these four nodes can be like connect to one another over like TCP and they more or less play a little consensus game to decide what they're going to sign. Every time that there's a validator Duty coming up. They play little consensus game pick. This is the hash we're going to sign and then every valid are client Even the exact same, you know, hash to sign. They all, you know, check it for slashing rules, do all the usual things.
What's nice is everyone gets to keep their own private Key Management. You know, the oval software is just kind of read. Only the Middle where it doesn't actually have the power to sign anything. So all the independent validators, check that nothing flashable. Once they're happy, they sign it with their piece of the private key and they broadcast to what it looks like their consensus client. And then in the middle, there are software like intercepts
them. Share them around with the other machines. And once any of in this instance, like a four node cluster, 13 of them like this. Three of the signatures of together, you can combine them into a full, valid signature, for the validator, and you can send that on which to the network. And what's neat about that is, you don't need all four
signatures. He actually can have fault tolerance and this is kind of one of the super important things about high availability is if you put, you know, a validator and for machines, but you need all four of them to be online, you're more brittle than you would otherwise be, but he put in for Machines and, you know, only need 3 to be online. This is where things really start to change and you can have
high uptime. You can do rolling restarts, you can replace Hardware that fails without downtime, and, you know, all of those good things and are kind of unlocked with distributed validators, So from a user perspective, if I mistake, ER, generally the options I have today is I can, I can either put it into a liquid sticking protocol. The line item would be the biggest of them I could go to a specialized validator shop, like a block demon, of course.
And I could spend about a P2P when I can spin up my evaluators there, or if I am usually technically competent than Then I can run my own validator. I've actually curious and of in these three, three, kinds of segments. Let's imagine that being liquid sticking as one segment. The other being the specialized validator, that's, like hosting
validators for you. If you have 32, eat third segment, being you want to run your validators at home, How would these three segments, kind of use this technology? And what difference would it make for them? Yeah, it's a that's a good question. So I'll talk a little bit about like our adoption path. So far the earliest adoption of oble has been at home
validators. They're the first ones to have put it on maenette, we put our first ones, you know, I'm a net between core team members all running at home and now kind of the adoption evolution is now getting into your hosted person and you know your liquid steak pool. Like what's taking place or kind of the earliest adopters of the idea and supporters of it being in their road map? So the I'll start with the at home validator, which is quite
interesting. So today we got home, validator, for example, like pushing grunts grunts one out of his house and like, we travel a lot today for for, for like purposes of oble. And it's always, it's like kind of chronically offline. It's kind of this thing that you have to worry about it. You can't really have peace of mind for being an at-home validator today, which is something that like DBT can
unlock for you, right? You can have your at home machine, you can run backups inside of the cloud in an on / about way so that you can ensure you can kind of live your normal
life. The other side of the at-home validator is Persona type of I don't have 30 to eat but I trust myself to run my own machine and there's actually like quite a lot of those people and they can You zobel to come together to like create their own shared validator because they may not be interested in taking on the risk of the pool.
And you know, they may not need a liquid stake token but they don't have 32 week and that's kind of the squad staking concept which we've seen honestly take off quite a bit in the at-home validator category which is you know a whole group of people who's like you know some of my eat is in a pool. The rest of it, I just want to run myself but I don't have a full validators work which has been quite interesting so yeah
it's peace. Mind. But then that second user group is actually where we think most of the tail end adoption for DVT will be in like 10 to 15 years is like enabling just groups of people to get together to run their own machines and giving each other fault tolerance and like a human to human manner. So yeah, a lot of early adoption there but the middle adoption of DBT won't be there in my opinion. They're like the early
enthusiasts. They're the ones that help set us up our primary duty is to figure out how to give you at home. Validator more tools to get more Them online. And now we're bridging more into the hosted and like liquids taking full category. So now I'll get into those two different types of users and you know why it's beneficial for them for your liquid staking
pool. It is actually the most Innovative use case of DBT today because most of the pools are using it for its Byzantine properties which is quite cool. So the example I like to give is let's just, you know, use a
hypothetical liquid state. Pool today, there's 10 validators inside of this liquid, staking pool, all of them are supplying their own, you know, keys to the system keys that they create keys that they manage and keys that they run on their machines again, in a very monolithic environment.
And the reality is, is that like, in each in this liquid, like this hypothetical liquid staking pool, each of those, validators would have like a certain amount of steak that they're responsible for, and that person can actually self /. They can be You know, they can sabotage, they can act malicious, they can't take the phones, right? But they can shut the machines off, and they can like bring
penalty to the greater pool. If you will, when most of these pools you social economic, so it does mean that like it could take, you know, it'll hurt every single participant in the pool. If one of these validators defects and it doesn't even need to be malicious, right? It could also be a bad day at the office where like, you know, all your servers crash and everything goes down or it could even be catastrophic.
Right? Like you have a rogue employee who steals the keys and, you know, there's a variety of different things that can happen inside of that, construct. So when DBT enables is that, that group of 10 people can, now just share one validator, which like creates this whole new defect in Game Theory between the different operators in that
cluster. It gives fault tolerance and it makes it essentially, I hate to use the word impossible but it makes it very, very difficult for 81 validator in that group to do. Do anything malicious or defective to that pool. So that again like its availability and slashing protection, reasons and utilizing it for the fact that there's a consensus mechanism and it prevents Byzantine Behavior.
So it's one of its true, you know, corporate motives the other reasons that they're using it as not only for that but they're using it as well to decentralize their validator set. So if you're going to build a liquid, staking pool that wants to be very decentralized, then. You're going to have to invite, call it middle to lower to sub.
Tear validators to like decentralize the validator set over time, and you need to do. So, in a way that protects the pool, especially if it's an existing pool. And most of the pools today, like my granny DBT, our existing tools and there's lots of money inside of all the fun, right? So, if you are going to let new validators in, you need to let them enter the pool in a manner. That does it hurt the pool and DBT is a great way to do that because you can just build some
shared values. Alligators, you can partner, you know, three highly proficient people with one newcomer and then, you know, you have some fault tolerance. There's some give there if they make an error Without Really harming the pool. So yeah, the decentralization of the validator said is also a very interesting one for pools and the use of it for its Byzantine properties your hosted. Service provider is actually someone that we thought would come later in the adoption
cycle. However, they've come in quite quickly and it's a factor to do with the centralized staking product or the hosted product is was the first product in the industry. It's been competitive for a number of years now, it's like entering it's fairly normal maturation, cycle of compressed margins and increase costs.
And now those products like need to mature themselves in a way where they decrease their costs, but they improve their security as being a centralized for Vidor like requires saw to Sock one compliance. These things help to kind of institutionalize yourself. And most of these people have to offer some type of off chain Insurance mechanism, which is quite costly to do, or you just have to be pretty well, you
know, bankrolled. So, for these users, their maturation and growth is meeting DBT, kind of in the middle and they're experimenting with it to help scale their operations in a way, where they can decrease the amount of machines, they Need for a certain amount of each while also, increasing the
security profile of that setup. We've seen a lot of interesting things recently in the insurance and reinsurance topic around DBT offerings, taking insurance has been difficult historically because, you know, the definition of a bad day at the office is losing all your Easter potentially, but that was just at the beginning. And now, we're as a community DBT, being one of those Technologies building things, Like alleviate worst case scenario of like you know losing
all your needs. So insurance providers have been interested in kind of including DDT into their criteria of providing Insurance because it gives them more assurance that like, you know, you can't lose all of it. It's not an absolute loss situation. So you know. No insurers. Going to ensure something that's an absolute law situation and Technologies. Like DVT have now come in and helps like alleviate that so yeah.
The Three core user groups. I think the fourth one I'll mention is kind of defy and how defy has thought about using DDT. So like in most D5 projects today, you're like taking an asset in your wrapping it or you're taking a collection of assets and you're pulling them together and you may produce a stable coin from it, right? Or you may produce other streams of yield or income off of a collection of tokens, the collection of tokens that people
are using today. They are LST tokens like would stake tokens and they're doing a variety of different things with them. Those products since there's a product built on top of it, it's better for those products at those liquid state tokens RSD wrist as possible. And now, people are looking at what is their risk criteria and mostly they haven't been looked at the only risk criteria that an LST token has been looked at to date is liquidity because that was the biggest risk. Right?
How liquid is this thing? Like, what does that look like? But but now it's more Or less like okay, what are the potential penalisation properties of these lsts and under the hood? Like what types of security protocols and parameters? Are they using for it? So now we've seen D5 who has like its own interpretation of bris. Honestly. Probably a more mature interpretation of Chris than the
validating community. And now DBT is kind of come into their Spectrum over the past, call it month or two, which has been very interesting for them to want to include. Glued it in their ecosystem and to learn more about it. One of the downsides of a DVD like setup is that it adds extra cost. Meaning you know what's the
what's the other case? Let's say you have a hosted service provider and they're running a validator on some some Cloud probably Amazon or Google and they have an engineer there for up time and they're running it on a single machine. They won't have 100% uptime, but they will get to somewhere higher than 99% of time just on on on that sector.
Now, when a, when a DVD set up comes into the picture, you're running like three or four machines and usually spread across different parties and you're also adding some kind of key setup and key tear down cost, right? Like, probably the setup of these systems will need some extra extra work. It's one of these cases where you are adding fault tolerance, but you're adding cost.
And sometimes the custard customer cannot perceive the extra fault tolerance meaning that they will go to some kind of log explorer that will say, hey what are the returns of the validators and the evaluator, with 99 up percent of time running on one machine, they return will be X and then they will see the DVD set up and it might be marginally better like X Plus in 0.1 percent or point zero five percent. How do you have a dress that address that At issue.
And do you see that issue in in practice? And what does it mean for the different parties and you might end up DVD? I love this question because it actually pushed back a little on increasing cost. You're writing that increases Hardware. But depending on what people have done before hand, it doesn't necessarily increase their cost and what I'm kind of
getting at you. Kind of talked about it in the cloud is originally without distributed validators and the real problem was that there was more or less. No safe way to run a backup and the only kind of option. You had was do some sort of monitoring game and pray that you're monitoring is you know, a perfectly reliable. And there's not a scenario where you turn onto machines the same private key at the same time and and the problem would not be
able to run a backup. Is it can be very hard to recover from a failure and particularly if you want to use something like a bare metal machine and like a data center somewhere, that's usually one of the more low-cost ways to run a
server. And the problem is, if you do put, you know, particularly large amount of private keys on a bare metal server, like that, and it just goes, Flying which is regular occurrence of probably happen at least once or twice a year and you just kind of have to sit in your hands there's more or less nothing. Say if he can do at that point well you can try and bring up a backup and hope to shut down the back up before the primary comes back.
Or you can bring up the data center and ask them to kind of go and like pull the plug out of the wall. And but this not being able to like run a backup and has changed a lot how people have, you know, build their architectures in the early years and most of these centralized I
say Moses not quite true. Lot of centralized providers at least started running in the cloud and particularly because then, if you do have a failure of machine, you can kind of detach the disk, you know, it's all in software, you've a lot of power to kind of actually recover things that you don't have when it's just a server sitting somewhere. And but the problem with that and you kind of alluded to the fact that they might run one machine.
A lot of people, they'll have at least a few servers in the cloud. Normally they'll have kind of, at least two, the runs going to Els and ciel's and which is kind of the Meat of it, then they'll have a machine with their validator on it and plausibly, they'll have some more with key manager on it as well. So a lot of people like kind of Enterprise taking validate. If you talking kind of 327 Cloud servers and Cloud Server, the much more expensive than a bare
metal server. Rule of thumb, think about 10x more, including one of the real kickers is bandwidth costs which I'm sure you guys are familiar with egress but that can often take up Scent of the kind of operating cost of a cloud validator. So you start to pile on egress multiple cloud machines and so on. And it really starts to end up kind of costly.
And that's kind of where we one way to have, you know, high uptime without distributed validators is to kind of put it all in the cloud have a bit of failover and do things that way. The other option that some roots go down, is they kind of do the hardware route where they'll buy a particular server that has Jewel. CBS, Sockets live two CPUs.
They have a raid array of disks. So if you want disk fails or problem that have dual networking cards, so, you know, if there's problems there, they'll survive, maybe grps use. But these PCS cost in the tens of thousands of dollars and they're not particularly cheap. So either, you know, trying to get kind of fault tolerance by using cloud services or fault tolerance by using really expensive Hardware. Both of these are, you know, not the cheapest expect a lot of,
you know, some of these tax, if you're running. 7 machines in the cloud, you wouldn't feel spending a couple thousand, maybe three, four thousand a month, for something like that. And if you then have distributed validators and and you can have private Keys like split into groups, it opens up the ability to more safely put validators on bare metal machines. Because if one of your four machines dies, no big problem. It will stay online. You can kind of wait for it to
come back. If it doesn't come back, you can bring up another, you know, partial on another note. It's not going to cause a slashing, it doesn't have a phone. Key on its own. All of these machines are doing consensus beforehand.
So kind of what we talked, a lot of the centralized providers that are like, how could you know distributed validate is possibly not increase my cost and we tell them that, you know, with software fault tolerance you can move away from like cloud-based Solutions. You can move away from having like extremely, you know, fancy Hardware, based Solutions / up
time. And instead, you can move towards commodity bare, metal, and use just fault tolerance to Do it. So instead of having, you know, 4274 on the books and month nodes that run in the cloud, you can have, you know, a hundred dollar month bare, metal machines, and your full stack and cost 400 a month instead of 4K a month. And yeah the last kicker that is, can you do it at scale with high load? We're doing running a lot of good test in that regard.
Seeing if we can do this at like you know, thousands of keys as well to improve margins but yeah, naively in the scenario. Yes, you running more than one note but bear the homestake or Most Enterprises most you know, operators within the ESPYs, they're not running a single machine. Unless they're, you know, doing something with very fancy Hardware. They're probably running at least a few machines. So distributed validators and having fault tolerance allows them to kind of.
Yeah, use cheaper servers less, you know, not over pretty over-provision them as much. And we are reasonably comfortable, buyer. You know, the people that are already running on bare metal. Have a very low cost basis to the very large amount of validator operators at least speak to that DVT actually will at them.
Reduce the costs. Even if they are running more Hardware, I think your question mayor's, well kind of present the this cell of DVT, you know today because look at the end of the day, it's a security protocol, it's not a yield protocol which is like, what everyone wants everything to be, right. Everyone wants to hear, like I'm not using your thing, unless it makes me more money, right?
And like, for us the fact of the matter is, is that it's a security protocol today, and maybe there is ways that it can get a validator Become more profitable, but it's not this Lottery mechanism that you download onto your node. And then one day, you see, 200 each sitting in your account. It's not one of those things. So getting people to adopt it, yes has taken quite some time but there's a reason for that because it is a security protocol.
So it's supposed to give you other things that benefit you in the event, that there's an increased cost for it. However, we think too. Oceans points. It's not only a benefit to them on the security front, but it will actually probably save them money on a relative basis today. And then in the future time periods up to us to kind of standardized DBT as a configuration. And what we like to use internally is that we've been calling this like the old bull inside strategy like similar to
in tow right? Like what intel was able to do so I basically Really standardized. It's the inclusion of their chip into like everything and then the machines in the software and everyone else you know where the competitive market we think getting like oval on the inside of these things is far more where it's it's because it's a security protocol. So like how do you position a
security protocol in a Time? Wondering a bear Market into an industry where like, you know, everyone's looking for yield. Right there amazing I think yeah we talked about a little bit now the sort of cost from the operator side. I guess there's also double as this middleware that obviously you guys are developing. You spending a lot of resources on developing this and you also raised money.
So there's also like expectation obviously of this having some sort of business model, maybe if whatever you can share in terms of like how do you imagine like sort of oble to be adopted? Is it like The Operators that would pay Pay to run or ball is there like some other models that you've thought of to utilize or yes. Yeah, it's a good question.
So I'll tell a little story here and have been fortunate enough to observe like how they eat 1 and E 2 client teams like were developed and hardened and staffed and funded. And that's really kind of like the core of like how middleware Is and oboe and others. You know, what types of monetary streams, they'll be able to, like, take on and work with. So, like the early Foundation of etherium was, you know, there's
five client teams. I think maybe six actually on the, on the POS side and then I think maybe three or four on one side. But anyways, these are all kind of, you know, privately bankrolled. Now they're well funded. It took years to get to this. They were funded by the es or other like, you know, large donors and that software. Is free forever, right? So it's virally free. It's the primary network access to the etherium network. It has basic functionality, but
it's going to be free forever. And now like, you know, Danny Ryan uses the words, like, ossification and crystallization and really what that means, is that, like, the amount of innovation that takes place at that core client, level, and funding is going to lessen and lesson over time and new innovative. Space needs to be opened elsewhere. And now the new in effect like the new Innovative space that's being opened elsewhere, it is being enabled in this middleware layer.
So now we have this whole new middleware market where they'll be a variety of different protocols who are coming to add complimentary software to the core etherium stack and that middleware layer today. Has private funding but tomorrow cannot have private funding forever. Right. There's like there has to be a way for these middleware protocols to maintain themselves, but also continued the eat those of giving back and having regenerative economics. So today we think that optimism
has taken that responsibility. It is a responsibility at the end of the day. If you're building at this level is to try to figure out how you can make circular economics, some sort. So, the way that optimism has like built their Network and started to ecosystem, having a fee, which comes And it is then donated retroactively as a community to other projects that support, the core aetherium staking stag. So this is, you know, people like a protocol Guild. These are people like eat steak
or this is get coin. There's a variety of varieties like projects that require funding to maintain themselves on a different level of being open source, a noble and DBT. Sits at this new low enough layer. That, like, we believe it's our responsibility to utilize retroactive public. Goods in some sort of way, is the primary way that we start the economic machine where it goes after that, you know, is to be determined.
But there's a way for us to kind of use that economic model with every validator type, which is also the important thing that economic model works with your at-home validated, the economic model works with your hosted person. And it also works with your liquid staking pool and what other other future, you know, topic or use case that comes about, so yeah. Hi today. We're most focused on what is the version of retroactive public goods? That works for opal?
Right now, we're just like learning and figuring this out through this maenette adoption time. Period. You know, all those totally free today, dvts, completely free, you can go and, you know, play with it, do whatever you want. But like tomorrow, how do we Bridge into? Like a circular economic system? And that's our biggest Focus today.
I'm I'm actually curious if if you think the ideal place to house this kind of middleware Stack, I mean, the specifications of it might be actually something like the etherium foundation itself and then the client teams actually implement this middleware as part of their, as part of their code bases. Yeah, so this is, this is ABO be
too. Today, we are on our roadmap to be one at the moment, we're about 60, 70 % to be one, but we've been working on a parallel work stream, which is OB to and all will be to like further protocol lies DVT by turning it into a specification. So we actually partnered with never mind for them. To be the second core development team for the oval Network. And they will be leading in partnering with the oboe Labs.
Current core development team for the oval Network to work on the research and specification of the Ogilvy to protocol and we are pushing towards a spectrum and environment where we hope to incentivize a variety of different. Implementations right for different peoples, use cases. And the reason that we're also doing that is to kind of the prior story that I told, which is you need to be as Most of the base layer from a variety of different perspectives as
possible. One of them is roadmap. You have to keep your road map on. You can't get in front of the mother ships roadmap. You got to kind of hang out in this Goldilocks time. Period. And yeah, those are those are the most important things that you have to follow and kind of stay on top of Yeah, the one extra thing I want to add actually about the middle right side, or as you said, like, why don't the client teams implemented?
You know, directly, this is something we looked at ourselves for quite a while, and it's actually why I touched on BLS signatures being aggregated by being so important. And I'll talk about it kind of by way of talking about May boost and before that even might get. And so for those of you that aren't familiar, have boobs, just now the product like run by flash spot.
Is that allows, you know, people that want to get, you know, inclusion into blocks without getting front-run, they kind of talked to validated through the software, but before it was called move boost. It was called may have get, and it was just like a slight modification to the original get code base. And they were like highly successful in their roll out more or less all of the etherium miners back in the day were running may have get to the
point that people are concerned. It was north of 90% of clients. And the theorem Foundation were kind of concerned about this. They were like, okay, if there's anything goes wrong with the software, you know, almost everyone is running it. So when it came time to move towards eat to and Reinventing it, to figure out how it works in this new paradigm with validators, one of the best changes they made was to re-architect my have get instead of it being like a forked
client. It's an optional middleware or oracular Leah, side care that all of the clients can add. And rather than it being your feature that only one specific client has the others don't, it was something that they could all opt into and this, you know, massively D. Risked it and allowed it to be more accessible and didn't, you know, prevent client diversity in any way. And we had kind of a similar like issue when we were developing distributed validators as well.
The easiest kind of way to make an MVP is to make a standalone. Validator client that has, you know, arbitrary power to sign. You can build your distributed system to go and run. The data is this way. Whereas yeah. Did the kind of problem here is either you have, you know one client that super successful networks?
Are you expect that everyone has to implement but if you do that, you kind of really slow your roadmap, you kind of have to get everyone to March along the same time and you really don't have much optionality if new better version comes along, people
can't switch to it very easily. So in the interest of, you know, not, you know causing harm while trying to do good when it comes to building distributed validators we Realize that we could also build distributive outages and as a middleware because of BLS signatures being aggregated level. So right now all of the existing validator clients they can add our software into their stack and become a distributed, validator more or less with no changes.
And this is super beneficial because it does allow, you know, you're not one client or you know, replacing them all or if there is, you know, a better spec comes out or, you know, although you know goes to 0 in the morning and you Can come along, all the clients can just put in a new middleware and it's much more modular and it's much more like fault-tolerant in that regards that, you know, if something goes wrong you know,
no big deal. People can kind of pivot and this, you know, design idea is why we kind of went towards the Middle where route and it's, you know, something that's kind of served as well in that regard. But the last leg of it is, you know, just one implementation of the Middle where is, you know, sufficient from a safety perspective but there could still be alive - risk. If you know the thing has a bug and it goes Offline that could be a problem.
Mm. So they kind of further leg of the journey is after you build ones, get some adoption prove, that it works, then it starts to become more sensible to protocol eyes. It make a spec have a couple implementations, but even if there is just one, it is still modular replaceable and is this, you know, nice thing that if a better, one comes along, no big deal.
You know, it can be swapped out. So I think that is kind of an important design decision versus why isn't this, you know, a spec that all of the clients To because you can iterate, faster, you can try more things, you can have more optionality and that's kind of the way we've designed the software so far. Okay cool. I guess we also wanted to sort of talk about how mobile interacts with other middlewares in the etherium stack so you already mentioned like meth
boost here. I guess that that might be a good place to start. We're like in my imagination, right? Like I guess now, we run this opal. Cluster, like all of these nodes in the cluster also run meth boost. Do they have to make basically consensus on in terms of like what sort of block you accept their or can you Talk a little bit about how how this interaction works.
Yeah. And so it's relatively straightforward because may have peace talks to the consensus clients, whereas, we're almost a little layer lower down talking to kind of validate your clients and you ask a good question about. Do you have to kind of come to consensus on what's provided and Maeve? Boost is a bit different to, you know, a normal block proposal in that and the fear is that if you have, you know, a block that's extracting out of V that's, you know.
Yeah. Taking I can emphasize rewards and the Searcher, doesn't want to show the proposer. Exactly. The full block because then the pros will be like, oh thanks for the alpha. I'm just going to rewrite this to send it to my address and I'm just going to propose it and this was actually one of the reasons around the kind of redesign of meth boost.
Now, when I move towards proof of stake was, if we want this to be available to every proposer, we needed to Helo trust because you know in the eat one world there was only a handful of minors so you could kind of trust them whereas in you know eats do the hope is that there's a huge amount of validators so you do this does need to be low trust. So what actually happens is the relay in the situation is actually the kind of trusted party.
They have the full block, they know, you know what it is and they promise, you know, not to Rogue or like undermine the Searchers and you know, school with them. So they just provide hash like are like the header of a block To the actual distributed validator. So at that point yes the nodes and do come to consensus on, you know what one to pick, but there is, you know, there's not too much that can go wrong. There's not a full block there, they cannot reorder transactions.
They can just say, hey, you know, this is a Blog header, it's going to pay us. This reward, are we cool with this and everyone says? Yep, cool. That sign it and send it back to the relay who then brought pens the real block and sends it on words and say, yeah, that that would be How the men have Boost kind of integration works and do you want to talk about some of the other ones?
Maybe? Yeah, I guess the other thing we want to talk about here is also like, sort of a trend that kind of coming up any Theory. I like Reese taking and I'm layer like sort of re utilizing your collateral or it if you're in validators to offer additional services like let's say it may be Oracle or whatnot and I guess that's also like first of all is very The hyped, I guess, but also seems to interact with with, oh, ball on the front.
That, you know. Yeah. How how could like Reese taking service will be offered through a bowl? I guess that that would be something that I'm personally very interested in, for sure. Yeah, it's a great question and something we're chatting quite a lot about at the moment, these days.
So I talked about, so we're talking to them for the most part, about a project called eigen layer is introduced, this idea of restoring, Taking. And as far as how old ball fits into the equation, this kind of two ways that we fit in first as a Staker, which is, you know, the kind of Crux. These are the people that are, you know, pointing their withdrawal. Address of their validator, at a, you know, an igon layer, smart contract and opting in to
be the reef takers. Like, yes, you know, we will provide Economic Security for some extra I think additional validated Services, what they're calling that the other thing and From mistaking perspective we think distributed validated snowball is super important because if you are trying to you know sell your Reese taking solution to these other services that are you buying Economic Security from you?
You want to be extremely sure that the steak underneath you is safe and secure, because if something goes wrong and they all get slashed, your Economic Security kind of disappears. Technically, you know, they'll be able to, you know, Charge the person to get slashed and they'll get penalized for it. But if you're, you know, maybe running an oracle or something and depending on this, if there's a mass slashing under you all the validated get exited.
So your Economic Security just kind of disappears on you all of a sudden and that's you know something that you can't really are you really don't want to happen if you're trying to you know, if you're you know additional validating service looking for you know Economic Security you want to be sure that the validated need this Rock Solid. So this is where Distributed validated is really kind of add benefit for the kind of Reese taking Paradigm.
It's like, yes, you know, this steak is run by groups of people. The odds of it being slashed or quite low, the odds of it going offline are quite low and that kind of gives you a more firm based actually provide
guarantees to extra services. And then, you know, going a little further or ball itself could reward and penalize people within a distributed validator by using this kind of reef taking and Economic Security. T and this is, you know, the kind of further version of Leo in the near term mobile can be a Staker for something like I can layer, but in the longer term it can also be an additional validated service that, you know, being the one paying for economic security or for Reese,
take to keep it, you know, protocol running and CI weirdo. Quite bullish on the idea of having distributed validators, be a safe base to Reese take on Yeah, that's that's really cool. I like personally was thinking, you know, also since you know I guess there could be a lot of additional services that are offered through angle, a right and maybe for a single node, operator can be hard to run so many additional services. So I guess. Do you think it's possible that?
Like for example a oboe cluster sort of shares, these responsibilities like one guy runs their Oracle the other. That's a hundred percent, right? Yeah. In the, in the near term, the be bit of trust involved. If you're a, you know, saying hey we will put our withdrawal contract, you note or diagonally, I will trust my hair is going to run that Oracle for us. He's not going to get a slashed. You can do that.
Absolutely. And you know we could all be taking the risk of, you know, doing that extra additional voluntary service each and put going even further. We're working on the cryptography to make kind of proofs of kind of, you know, Fair participation more, easily provable. And here's a scent that they're like the longer term. Goal. Is that, you know, one piece of this distributed validator could opt into this service for everyone?
And if they do screw up there, the one that takes the hit or eats, you know, most of the blame rather than the whole group sharing in the, like, slashing, if, you know, one person who they like trusted to, you know, do some extra service for them doesn't like match. But yes, you absolutely can
have. You know, one person in your cluster doing all of these extra validating services for you Yeah, maybe this eigen little ecosystem would be so large that specialization of Labor will emerge, meaning some validators, do some things, and other evaluators, do other things. And if that kind of specialization of Labor, emerges then, o ball, is kind of perfectly fit for for exploiting, that specification, be specialization. But it's still early days, right?
Like there is not not a single service that's actually running on this Reese taking model in product 10. I think they announced their no not in production, they announced their spec and stuff, I think this week so shout out to them for that. So yeah, they're working away in it. We're keeping an eye shadow way is is the overall concept only applicable to etherium because of its special staking model or is it also applicable All to other chains. Could you expand to other chains
and deliver utility? Yeah, it's a good question. So what we've been thinking about DBT for aetherium, validators for three and a half years at this point. So I made it a pretty large effort at the end of last year to be like, hey guys, it's time. We have to go look at where else we can go right? Like this technology, most likely will benefit other ecosystems or other layers of the theory of, for example. So we went on this effort to kind of go find problems recently.
So we spent the entire fourth quarter. Um, and a good portion of the first quarter on a cosmos effort, which, you know, the team at course, one was very helpful with and a lot of the other causal is ecosystem as well. We've also over time when we'd like our first and second fundraising round kind of had this emphasis on like what is the second ecosystem that we think they're smart people. Working in that have the right, you know Mission and like the right vision and that was caused
most investors. So the ecosystem itself already has a pretty actually large Cosmos presence in. It today as a zobel. So we decided to double down on that fact because we had the best access to information and we figured we could like learn as quickly as possible succeed. Quickly fail. Quickly, kind of one of those, you know, mindsets. So we went into Cosmos and we started looking for problems. We spoke to the validators, we spoke to the liquid staking projects.
We spoke to the ICF, the folks at the builders program, we kind of did this whole Loop of going through the whole Cosmos ecosystem and speaking to people and looking for problems. And we were able to identify, you know, a couple structural problems is to how DVT could be useful for smaller. Validators, for example, in Cosmos to team up to get more delegation to enter the active set. There's kind of like this larger portion of Cosmos validators that are like chronically unprofitable.
Even like some of the largest, you know, cause most alligators aren't necessarily that profitable today either. So the smaller to, you know, middle tier ones, there's really no game for them unless they could maybe team up together, right? Right? And attract delegation through, you know, means using DDT. So yeah, we found some good problems in Cosmos. We published a blog post on it recently, you know, there is coordination difficulties to making it a reality there's
protocol difficulties. There's cryptography, differences for example, Cosmos does not use BLS signatures, but we also learned through that effort that if you wanted to get it done you could and there's kind of like a existing versions in the cosmos ecosystems that are about, you know, a third of what DVT. Is but there would be a lot of builds inside a cosmos. That would be necessary.
One of the most interesting things that we found about Cosmos was actually the kind of social threshold of the value of DVT and inside of Cosmos, what we realized is that there wasn't enough value at risk for people to think that it was something that shouldn't just be, you know, an open-source primitive.
They couldn't believe that it needed to be a network with all these, you know, tools and education and funding and ecosystem around it. But our take from that was that the cosmos ecosystem is almost mature enough to have enough value at risk for everyone to say like, hey, we think this is a good technology to adopt into our community.
So, for us, we believe that it's a little bit early for DBT in Cosmos, but we are still actively, like working on implementation based research now, So we like stated the problems and now what we want to present to everyone is kind of like here's how it could be implemented.
So yeah that's like one area of alternative layer ones outside of it. The area where are our communities aligned and we're experimenting to see if the compost Community Values, it and then will, you know, collaborate with it. The other area, which is actually super exciting segment. Just put out a piece yesterday around distributed sequencer technology.
A new term that we're trying to coin and this is the Then the other research area for us at opal, is just going up the stack and looking at your other actors, right? So today we've spent all this time on the validator. Well, let's go up to the block Builder. Let's see if there's like centralization problems around block building people talk about MVC block building, right?
All these different constructs. And then we've also been looking at the sequencer and like the approver, the verifier, all of these new actors that are becoming more and more important in the core etherium infrastructure stack and looking
at their adoptions. Eagles and saying like is there a need or is there a re use case for the work that we've done for distribute validators and all the stuff that we know we've learned from an external project building it not from a foundation perspective actually which is the reality of where layer 2 is there a bit more mature and there we sit outside the foundation. We do our own things and we do
whatever. So you know flab rating with those new groups of people has been quite an interesting experience for us so yeah we're we're actively looking. Two different growth strategies for DVT to see if I can be helpful elsewhere. One of them is horizontal, that's Cosmos. One of them is vertical that's going into the sequence or topic and seeing if our technology could be helpful there, Yeah, very interesting. I guess I would also like, just like to hear your thoughts.
I guess you're like, very close in the end to like both the validator ecosystem and sort of the other protocols. And and I would just like sort of like to hear how you currently think of the validator ecosystem. And how do you see it evolving? I mean, obviously sort of like one of the core ideas of the theorem is that there are these
homes takers. Like do you do you think that like they're you Are much of those and will this grow obviously a global potentially might help increase that, but I guess just generally what's your view of the space. Yeah, I've been surprised thoroughly at the number of like, hybrid at home validators, I would call them, right. They're basically like small groups of at home. Validators who are starting small companies together and there are tens and 20s and they're like growing by the
number, right? We kind of call them like the tail end, validator segment and that's probably growing the most, right? We're seeing a variety of new and small value or entity. These pop-up we're starting to see people from other ecosystems come to etherium and by means of
coming to etherium. They're doing so through DBT as actually their first knowledge base which was also like a very interesting thing is in our onboarding validators from other ecosystems, not into the core configuration but into the DVT base configuration from from the very beginning but are probably some of the most like bullish honestly and exciting conversations. We have with people are in the like, hey me and my three friends just got together.
We started a company we're looking to like you know get involved as a validator and light. Oh we're looking to try to qualify. There's there's a variety of small and mid, tier validators that are trying to get voted into light. Oh, and by means of increasing their chances, they're spending a lot of time with Oberlin DDT, to make sure that they're proficient and that make sure that they're educated by it.
So honestly, there's a lot of really good inertia at the smaller end of the validator of embracing DDT and like using it too. Advance themselves so they can become more professional. And this is surprised me. This is not, you know, like like a segment that I thought would be such a core user and like, Pusher of the protocol, but I think it's really like a. It's a sign of like the ethos of
the theory. Mm, it's like kind of crazy to see actually write like that group of people feels empowered to go build companies. So that's what they're doing. And then they're using obol as a further like empowering mechanism. To achieve those goals and it's quite fascinating. So in the etherium roadmap, we have this, this dank sharding concept that's coming in where essentially these validators will end up becoming responsible
for data availability. So if you have like a single centralized validator, it's kind of probably easy to understand, we have to store some some kind of data on our side but how does it interact with a no-ball cluster with there might be three we're like three different parody does does it data? Now need to be replicated across all three? Good really Niche. Technical question, mayor.
And so on, this tank sharing is coming out in two phases, the first one being prototyping sharding, and the second one being folding shouting in Frodo dank shouting, they don't go to the extreme where they don't have every node in the blockchain kind of keeping and gossiping like all the data availability. It's still, you know, everyone sends everything everywhere. And If eventually with, you know folder, Shouting you're signing data, availability witnesses to
prove that. Yes you know I did see this data was available and oh yeah over the longer run there starts to be you know trust assumptions between the the four nodes trust them strong word but they have to decide. Did we all see the surgeon at least any of us see the speed of data blob so that we can include it in our block and like sign to it. But in the near term and prototyping shouting when it first comes in, it's more as a best. Effort data availability.
It's done at the consensus layer and it's not, you know, you won't be slashed or to my understanding or at least they're not putting, they're not going to the side where, you know, all nodes don't store everything which is the first wave comes in. So yeah, when it comes in a prototype sharding, not currently problem.
When it goes to folding sharding, the nodes do have to say have we really seen this and you know we have to kind of prove yourself at or as you said if you don't trust one another everyone see the date availability before we sign off if you want to be More cautious rather than more trusting. But yeah, it's in the near term. It should be problem. And then also, we proposed a builder separation.
A lot of the complexities of dang sharding is on the Builder and the proposers it keeps the proposes relatively simple. They just have to kind of propose the really fancy block
that a builder made for them. Maybe I like to end with kind of one of the conceptual doubts I have with this entire aetherium Elder roadmap, which is that sometimes I feel that via meaning like ZZ validators and, like, you all of these middleware Builders. We spent so much time and effort building various products to make the etherium, validation system work and be decentralized. So many thought Cycles have been spent here.
And now when it comes to the question of scaling ethereum, most of our effort is kind of it feels useless because it's going to be scaled through the L2 is now. These Elders are going to be running sequencers, and that's like a completely different kind of validation stack, that's
that's being built. And like now you have noun, for example, overall instead of reusing your work for etherium directly to scale is helium in L2, you now have to go and think of this new concept of a distributor sequence and wrongly Android new software. Same for us extra. Do you in some sense, think you're all our efforts are kind of like not being wasted but being underutilized by the
theorem ecosystem. Yet throwing all my favorite questions, my hair because I actually would suggest that we don't have to throw stuff away and, you know, build new software and stuff. And this is the idea of a theorem equivalents that I think was kind of first coined Again, by optimism, but they kind of astutely realize that if they stay as close to the etherium execution architecture as possible. It's easier for, you know, to gain adoption and network effects and be able to reuse all
of the existing L1 stack. And for example, their very first kind of MVP will call it was, you know, a modified, get not unlike maybe get to some extent. And then recently, or just in the coming weeks, they're moving over to optimism bedrock and the main difference, there is David abstracted all of their kind of code for the optimism kind of fraud proof game, and into what they're kind of calling a consensus client. And they talk only through
Engine API. The standard one that all of the execution clients use and adopting, this kind of standardized API for them, has allowed them to go from having, you know, Opie get to also having Opie Aragon and ultimately, probably all of the existing L1 execution clients in the optimism world. And we recently like, announced a Blog with segment just yesterday on distributed sequencers. And the Crux of the argument is exactly, I'm yeah, altitudes of already.
You've competed only theorem equivalents at the execution layer. The next step in our head is to add and etherium equivalent Beacon API to their code base of the. So adopt PLS signatures adopted API, dumb it down a little. It doesn't need that to take attestations because it's not a proof of stake game but just have, you know, proposals using that standardized API and the benefit of that is you do get to reuse more or less everything from the L1 particularly from the L1 staking side.
The ones probably most important is the private Key Management side of things. So, you know, private keys are always the most important thing. So if you if let's say optimism for Simplicity, they add a beacon API to their L2 lycopene owed stuck. They can reuse web three signer, they can reuse Dirk and you know the benefit for all us they can reuse distributed validators because it uses the same API and they can more or less use it all out of the box.
So yeah, I I hear where you're coming from being, like, should I choose really invent the wheel and I agree with you, they probably shouldn't they should, you know, copy the L1 apis, as much as possible. And then they get to kind of tap into the network effects of code. It's already built and already been used. So yeah, pitch to them is you don't have to do all of the decentralizing, sequencer work yourselves. You can keep it a little simpler.
Have it be kind of a round-robin thing with BLS signatures but then use distributed validator to actually go from, you know, 10 entities and round-robin to actually 10 distributed sequence, Errors in round-robin type of setup. So yeah, I agree that, you know, L 2, I think, you know, generally will adopt this. They kind of see the network effect trying to build something new and convince everyone to come. Easy stuff.
Is hard trying to, you know, stay aligned with the existing apis more work for them, but, you know, more Network effects and easier adoption for their customers, and for everyone else, right? So actually, actually, this then seems very powerful for the old bowling Network that You can effectively go to an L2 that has.
Let's say a centralized sequencer and maybe your product is simply that instead of now this being a centralized sequencer, it's actually distributed across five parties or six parties and then if they can work out how to go from one centralized sequencer to five and each of them now is a no-ball validator with like five or seven. Then you can Autumn easily get to 25 or 35 people running the infrastructure eggs. Likely right. So so all of your work done for is helium, kind of Yeah.
Scales like probably is more useful on the L2 layer, then, maybe you're even on this idiom mean. Net like that, could be a future for that. Could happen for the overall project. Yeah. That was actually something I also pitched where seek like in the L1 is normally very small machines and there's technically you know, 500,000 validators, but sequencers, they often will be running like very large
machines. So you know five very large machines run in a distributed sequencer setup makes a lot of sense rather than you know, thousands of small machines. The l2's. Mostly won't optimized for like running on consumer Hardware. There, you know, meant to be a scaling solution, but they do want to be, you know, as Trust.
- as possible. So yeah, big sequencers that are running a distributed validator type of setup where if one of them becomes malicious nothing happens they just you know like stay online like a multisig, is it? Yeah as I actually agree I think really makes more sense it out to than either one and by others majority side of things. Perfect. Yeah. Awesome. That we went very deep. Thanks so much for a dank episode emotionally Colin. And yeah, thanks for for coming on the epicenter.
Maybe add, before we wrap up. You wanna shout out where people can learn more about, oh, bowl or yeah? How they can find you and they are. Again, thanks so much for coming on. Yeah, thank you guys for having us. It's been a great discussion. He had to find out more about obol, best place to probably linked into the communities through Twitter. You can just find us a doable Network and we have a cool ambassador program. We have a great Discord, we just well tomorrow.
We're actually launching our Research Forum with the distributed sequencer. Peace, as first one for people to get some debate on and then we'll actually build out the cosmos section of the Research Forum. So if you guys are interested in getting involved there, In the next. Well this proposal. Yeah. In the coming days, you'll be able to see it. And yeah, I'll pitch the sheen but thank you guys for having us and really appreciate it. Yeah. And nothing. Major. Dad, thank you very much.
This has been super fun to talk in the nitty-gritty of validators because normally we don't get to talk about. You know bare metal version of cloud versus Cosmos or L2 and their architecture. So I'm going to be a grateful of this chance for to get really into the technical nitty-gritty and podcast. I hope they're all as technical as this one. Thank you for joining us on this week's episode. We release new episodes every
week. You can find And subscribe to the show on iTunes Spotify, YouTube SoundCloud or wherever. Every listen to podcast. And if you have a Google home or Alexa device, you can tell it to listen to the latest episode of the epicenter podcast, go to epicenter, .t V /, subscribe for a full list of places where you can watch and listen, while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as they're released.
If you want to interact with us guests or other podcast listeners, you can follow us on Twitter and please leave us a review on iTunes helps people find the show and we're always happy to read them. Well thanks so much and we look forward to being back next week.