Ramon Recuero ~ #Buidling the Infrastructure for Adoption - Zeppelin

My name is Ramón. I work for Zeppelin, from Zeppelin Solutions and Open Zeppelin, and today we're going to talk about infrastructure for developers. To begin, I think the best way is for you to talk a little about yourself and then say what you're working on and why it's important. Hello, I'm George Zambellis, Chief Technology Officer at Climatex. I am working on a project called Utility Settlement Coin, which is a project to tokenize cash assets deposited in a central bank.

Neil Blake, Vice President of Product at Mainframe. We just released our first public version of Mainframe OS. Like many of those present at this conference, we are part of the large family that wants to change the way people create dapps and how users think about and discover dapps think about and discover dapps . I am an EV project leader at The Graph. We are a query protocol for obtaining data from blockchains and storage networks.

Therefore, we currently index Ethereum and IPFS data and make it available through GraphQL. Hello, my name is Igor. I'm from POA. POA is a company that focuses on creating scalability and interoperability solutions. We are known for the POA network, xDAI, which powers the current ecosystem for payments at this event.

And we create tools for developers. We have an open-source blockchain explorer, BlockScout, and an interoperability solution, Token Bridge, which is used to create the xDAI chain and other bridges. Brilliant. Let's get to the point. We 're all creating tools for developers here, but as you know, there are very few users right now.

So the question is, why? So the question is, why? Why are we lacking users? Because the usual answer is that there is a lack of infrastructure, but what parts of the infrastructure are missing? I suppose I would start with the incorporation.

So, if you want to use a dapp, you have to get some ETH, you have to install MetaMask, you have to go find an exchange, maybe buy a hardware wallet. So, at first, that experience will probably discourage people. Yes, when I said what he said, as well as the ability to discover. We want to create a home for users to come and discover all these amazing dapps that everyone wants to create. We want to offer a one-click installation that sets up a wallet, sets up an identity, sets up contacts, and establishes that scenario so you can find a place to consume these dApps.

Yes, I agree that user experience is probably the first big innovation. Obviously, scalability. But users don't come for the infrastructure, do they come for the infrastructure, do they ? They're going to come for the apps, and it 's too difficult to create good user experiences, good, you know, fully decentralized apps these days. Well, I think there are a lot of protocols missing, and right now people are creating these hybrids, and you have to create a hybrid.

Basically, what we should assume is that nobody is going to use an application that is worse than its centralized equivalent. And that's the bar that has already been set. Unfortunately, the previous battery had at least 20 years to mature. Therefore, it's much easier to create applications that are truly user-friendly for Web 2.0.

And so, we need to catch up. So, when we get to the point where it takes a similar amount of time to create a Web 3 application, and that application is as easy to use as a Web 2 application use as a Web 2 application , then, you know, it will be up to entrepreneurs to create good applications that utilize all these new capabilities we have to create engaging experiences. I would like to quote the co-founder of Microsoft. He said, "Developers, developers, developers." developers, developers."

TRUE? So, in our field, the most expensive and important asset for any blockchain project is the community, and the developer community is very important, developer community is very important, right? Therefore, I would also like to mention that you can do anything, but you can't do everything, right? When we think about developer tools, you know, each project focuses on something. For example, to me, it doesn't make sense to create a library for smart contracts like OpenZeppelin, smart contracts like OpenZeppelin, right?

Because, you know, why should I compete? I'd better contribute, right? But when we created our tools, we realized that a piece was missing from our open-source blockchain explorer, and we started creating it, right ? And now we see that the community is joining this project and contributing to it, and it doesn't make sense to start the same thing, and other projects can focus on, you know, different parts of the developer tools. And that's one of the great things about the Ethereum ecosystem, that we have so many different companies creating tools for different parts.

And if you look at the ecosystem as a whole, you can see that, you know, you can create a lot of things, right? But you can't create it all alone. So that's one good thing about collaboration between all of us. Yes, I really like what you said, that in the end it's about offering a better product for users. It doesn't matter that it's decentralized.

Most users are not going to use something just because it is decentralized. We need to offer something that is 10 times faster, better, or let them do something they couldn't do before. Well, regarding our users Well, regarding our users , I'm curious, how do they inform their product decisions amidst this uncertainty and immaturity of the entire ecosystem? Yes, I suppose I can perhaps provide some perspective from a business perspective. Therefore, I believe that for our use case, the technology has been proven.

It can handle the use case we need. And now we're moving on to integrations. And I think the tools are still pretty bad. For example, libraries to integrate traditional systems, perhaps libraries for some of the older languages ​​used in financial institutions. Therefore, while I think the tools for creating smart contracts are quite good, they are not far from the Rails experience.

It's quite easy to implement. I still think that more tools and infrastructure are needed for business use and the business context. Therefore, our users are basically developers. I think there are probably at least 50 well-funded teams creating dapps with smart contracts. And that's already a pretty good start to working with user research and making sure we're solving real problems for them.

And then I think there's a much larger segment of individual developers. I do n't know what the exact statistics are . I think the number is quite variable. But I would feel comfortable assuming that there are at least tens of thousands, if not hundreds of thousands, of active Ethereum developers. And well, they may not be doing it as their full-time job yet , but they're hacking on weekends or coming to hackathons like this one.

So I think we just need to get in front of as many of them as we can, by coming to hackathons, working with developers. When they get stuck, they can come to us and we'll be right there programming together. I think those kinds of feedback loops make a big difference. Well, and well, I think there is already enough use to be able to build infrastructure that solves real problems. Well, yes, in our scenario, because we are building sidechains and sidechains typically need all parts of the Ethereum ecosystem to operate.

Well, when we decide what to build, we think, are we missing some pieces that aren't available? For example, Etherscan, right? It is closed source, not available for developers to modify. Sometimes it sends some data, doesn't accept suggestions, etc., right?

Well, that was a missing piece, and we decided to take this part. And the same problems there with, you know, Infura and MetaMask and then some other parts of the Ethereum ecosystem, unfortunately. He 's improving now. And it's also interesting, last year I was on the same panel, in the same room, about the same panel, in the same room, about ... It was more about interoperability and we've just discovered that it's possible to transfer assets between networks, transfer assets between networks, right?

About a year later, on this panel we have at least two projects with production- ready interoperability solutions that do not compete with each other, but can be used with different security models for different users, and have different developers who can contribute to these projects. TRUE? And it's great to see that our ecosystem is growing and that we're filling the gaps. And I think we should now look outside the ecosystem. For example look outside the ecosystem.

For example , what is interesting about Tron that we can adapt to the Ethereum ecosystem, right? And sometimes we think, yes, no, no, Tron is like Vitalik said, whatever. But they have very engaged users who are very interested in playing apps, right? So, they have fewer developers, but they have a very committed user base . And that's why its developers are more focused on B2C, and Ethereum was more focused on B2B, right?

At the end of the day, we're all salespeople here. Well, we all sell to developers and to each other, but unfortunately, we don't have many B2C applications, do have many B2C applications, do we? And in the ecosystem, we can see that they innovate differently, and we can apply this to what we are doing in the Ethereum ecosystem, for example. Yes, I agree. Well, I've been thinking about something, possibly the difference between a pioneer and an explorer.

I believe this conference is full of pioneers and explorers. And one of the ways I think I could explain the difference is that explorers don't have maps. The explorers go out, devise a map, and let the pioneers follow their example. And one of the things that still doesn't have a map is the user experience and how to get customers, how to find this audience. So, in a way, at Mainframe we are painting this picture of the future.

We believe we want decentralization, pure decentralization, and we know we 're not ready, and I think there are many people here who share that same story. But there are many places where we do this part correctly. And this is this 20%, this 40%, and we see other amazing 20% ​​and 30%. We were talking earlier about that concept of together, what do we like about Tron? together, what do we like about Tron?

What do we like about Zeppelin? And as we observe these spaces, we can combine them. We can create this map and then go back and say, "Hey, let's address this area. Let's address that area." And you know, all tides rise.

The high tide lifts all the boats. Well, I was going to say in response to Eagle, I think we've been designing and creating a lot of protocols and interoperability protocols, the Ethereum protocol, but it's real-world use cases that people are interested in real-world use cases that people are interested in . For example, Buffi Dai is proof that the protocol can be used and that it works, and people can understand it because they have it in their hands, and can buy a pizza. And I think that until we have more things like this, we will continue to talk about this in panels. So I'm glad we're not spending too much time trying to acquire new users yet, because I think if we were to allocate a large marketing and reputation budget to try to acquire new users to try to acquire new users , we might get stuck for a long time.

And so, it's kind of an exercise in patience and maybe even vision that we have, and we think, "You know what? I'm okay with investing years of my life in something whose results I might not know for a few years." And the truth is, there's so much infrastructure to build that there will be certain applications—and there certainly are some today—with which you could create a really engaging user experience, but it's a much smaller segment of applications. And so, you know, maybe right now only 1% of applications could be built engagingly on Web 3. And, personally engagingly on Web 3.

And, personally , I'm fine with that. Okay, we've talked briefly about the problems that prevent us from achieving mass adoption, such as usability and scalability. Let's say I'm a dApp developer like many of you here. What would you recommend to them when choosing tools, and how can they position their dApps for mass adoption? What are your tips?

Well, I guess for me the tools are pretty good. I think , you know, Truffle, MetaMask, In fura, you can get started very quickly. You can deploy an application, do an ICO if you want. But now it's about thinking more traditionally: what do people really want? Understanding the use case, doing some marketing.

Well, I think you mentioned that you have a marketing team, and I think we really need to be more aware that we're selling things to human beings who don't care about protocols or anything like that. So, yes, I would say we need to think beyond the technology and the tools to have a more business-oriented mindset. Yes, I would also like to challenge everyone here, and myself, that maybe we should n't borrow all the Web 2.0 metaphors. So, part of being able to simply say, what do we want the future to look like?

So, before we go down this path where we're building component after component on top of Web 2.0, maybe we're all frustrated with Web 2.0 stuff. Do we really want browser add-ons and other plugins for the next five years? And then, this idea that we can have the opportunity to reset What we want it to be, and we have the opportunity to have privacy first, we have the opportunity for the user to have a reasonable expectation of what security means to a non-technical user.

And it probably doesn't mean much. And then, to be able to go so far into the future and then work backward. So, I think a lot of us in this space are working backward because there are a lot of people working forward, and then we meet at a magical midpoint. I think the most important thing is just making sure that people are solving real plot problems. And then, you know, just like with traditional startups, if you're building something that people don't want, they're not going to use it.

And so, there's a kind of formula where you look at what the motivation is to perform this action? And then what's the friction in actually accomplishing that task? And you know, if my motivation is greater than the friction, then maybe I'll perform the task. And I think people just need to balance that and think about how much additional friction I'm putting on them and how much they want this thing, how much value they're getting out of it, and, you know, if you can make that equation work, then go for it. She.

I remember another good quote. You know, simple things should be simple and complex things should be possible, right? That's very important. And, speaking of Buffidai, you know, and I think most people who bought food here had this experience of, you know, a seamless peer-to-peer electronic payment system that works, you know, fast. And, uh, the important thing about Buffidai, uh, is that we have synergy, right?

And if you think about the underlying parts, for example, the XDai chain, which is like the first USD stablecoin and which runs on die, which I think is the most important stablecoin right now, and other parts like interoperability, which enables this kind of sidechain, and the cool Burner Wallet, right? And this innovative experience and thinking that users shouldn't, you know, immediately after launching the app, have to back up their keys, remember the seed phrase, and then do all these checks. You know, all these parts together create synergy, like 1 + 1 + 1. It equals a great experience for everyone equals a great experience for everyone . And that's what we should keep in mind when we think about user adoption because I remember when we started POA, the question was about scalability.

question was about scalability. Can we help existing dApps run on a minimum viable decentralized network, as I call it, with some security assumptions that are well decentralized and secure until someone can prove otherwise, and are audited and launched securely? And when we launched the POI network, we realized that many developers didn't want to migrate. They just wanted to wait for the foundation to scale this solution for them. And I think this scalability issue will affect many projects that were launched to solve this problem, right?

They have perfectly fast transactions per second . They have, you know, a fast block time and a huge block size. For example, a chain I really like because they did something very important. It's called GoChain. They launched a public EVM chain with 200,136 million gas per block.

Those are huge blocks. And you can put 600-700 transactions per second on its chain. And well, the question is, who needs that, question is, who needs that, right? If you solve the scalability problem, it won't bring in developers and users just by having this. But we can see that collaboration across multiple projects within the ecosystem can bring in solutions like Buffidai, which is, you know, fast and very exciting from a user experience perspective.

You're mentioning an interesting point , which is that building some of this infrastructure could arguably take a long time. It could take a few years. And then you have this tension between: Do we wait until it's done right, or do we do something interim, or do we try to launch something we can get out today? I think a helpful way to frame it is to prioritize shipping as soon as possible, validating things, and building them today, which is very important. We should do that.

But then you have this kind of turnover that you're potentially causing in developers, right? If every year we have to rebuild everything, you're going to burn out the developers. That's why I think that, to the extent possible, if we can figure out what the right APIs are for these different types... of protocols, then maybe you can start with something that runs on a sidechain today, but you don't have to completely rewrite your application once it migrates. That would be a really good way to solve it.

Great. We all have a privileged view here because we all build for developers, so we can all see what's coming. So, I'd like you to comment a little bit on the nuances of the different verticals that you see gaining traction on both the enterprise and consumer sides. Yes, I suppose what we see in the enterprise space is probably similar to what we see in the public space. People just want it to work.

They don't want to spend a day installing things. And they have a different mindset. They have things to do. They're busy. They don't have time to do big research projects.

So, they want the tools provided, and they actually hinder adoption when they're not there. So, you know, we're making some good progress with some libraries, but their motivation is to get things done. Yes, I also think one motivation is revenue for companies. And a lot of the conversations we have here are:" Oh, did you do an ICO? Are you going to do another round of investment?

"Or do they have a revenue model? If they have a revenue model in this current ecosystem, I'm very interested to know because that gets to the heart of discoverability. That becomes attractive to the company if they say we have a ready audience. So, it's really hard to tap into that company, and I think a lot of the enterprise space right now is advisory and consulting solutions, and it's not necessarily that these companies are making much progress in this space for usability and adoption. I think open finance is like the obvious answer to that question right now , simply because there's so much value to be gained if you can make money, etc.

And you're also willing to put up with a bit more friction if there's a high-value transaction type at stake, and banks suck. So, you know, compared to the alternative, I think we could already create some pretty compelling experiences, and we're seeing that. I think the other, you know, other interesting type of vertical is governance, and I think you could definitely say that, compared to the alternative, we can also build some really interesting things. And I think, you know, we're still in this sort of phase where..." It's still kind of a toy.

And then, you're going to have a lot of, you know, missionaries and believers who are here out of passion. And so, if you're thinking about how I can actually make the world a better place, let's start experimenting with different kinds of governance systems. I think there's already a pretty good market for that, a pretty good market for that, right? I don't know how many tens of thousands or hundreds of thousands of Ethereum developers or related people would participate in those kinds of experiments. But, you know, between protocols like Aragon and DAOstack, etc.

protocols like Aragon and DAOstack, etc. , I think you're already starting to see DAOs being built, you know, Moloch DAOs being built, you know, Moloch , you know, it's in the process of launching. Well, a really cool experimentation where they 're still early adopters, but I think some interesting things are already being done. I agree with the ideas about Dow, and when we think about, say, Dow and the underlying technology, the xDAI chain is controlled by Dow, like four companies that validate the state, but none of them can remove the validators without other companies. They have on-chain governance that can be done to comply through the protocol.

Bridge, which transfers the data to xDAI, xDAI is also controlled by Dow, and Dow is everywhere. Sometimes we don't call it Dow, but multi-signature, which can control some parameters, and there are some known parties that can modify these parameters; it's Dow. So, Dow is everywhere, and it's very important to create dApps and many decentralized finance applications; they're simply not possible without it, right? Like you couldn't build a bridge without it. You ca n't build many consensus models without it, right?

And also, what we discovered with xDAI is this new vertical called the emerging dApp chain . It's a specific sidechain, well, a shard, a parachain, whatever, for a specific task. And when we think about the details, we understand that the shards will be different, right? So they'll have different parameters. They'll have different, you know, native tokens, different everything.

And it's important to think of these dApp chains as diverse platforms, dApp chains as diverse platforms, right? But we need some common security models. I don't think they're chains of Relay chains bring too much centralization. And that 's something emerging. It's a very small sidechain, with a market capitalization of $9,000, one of the smallest public cryptocurrencies ever , right?

But it's used for transactions, and that's specific to programmable money, specific to programmable money, right? If you build something like a privacy- preserving sidechain , you could modify the opcodes to make, you know, less expensive, I don't know, cryptographic primitives that run on this chain, right? And it will be a different setup, and it might be a different, specific sidechain . So, that's something emerging. And some people were excited about xDAI and launched their sidechain based on the same idea, where the ERC-20 token can be plugged into a native token of a sidechain into a native token of a sidechain .

And let's say the Israeli project Colu launched its own sidechain based on the same idea and plugged in its token. And what I can see here is that, like most of these projects, they're very interested in autonomy they're very interested in autonomy . They want to be autonomous from total security. from other chains, but they're very interested in being in an ecosystem, right? When they can move tokens back and forth, get advantages from interconnected chains, but still want to have autonomy within their own sidechain, within their own sidechain, right?

That's a big vertical of depth-specific sidechains, basechains, shards, parachains, sidechains, but specific to use cases. Since we're already talking about sidechains, I'd like to hear everyone's thoughts on interoperability. What demand do you see from developers, and why should they care? Yes, I think we see a lot of demand ... we have Ion, an open-source interoperability framework.

We have Ethereum for Ethereum, also Hyperledger Fabric for Ethereum. But in the enterprise space, what's happening is that people are experimenting with many different systems and coins; even JP Morgan issued a coin the other day. But it's the same problem as in the public space, as moving value in this ecosystem is difficult. So I think, as you know difficult. So I think, as you know , we're seeing a lot of demand from our sector.

And we're seeing companies taking notice. Very seriously now. Yes, I think interoperability is a survival mechanism, even more than a good idea. I think if we have a long way to go to achieve this decentralized, or hybrid, future, and whatever it is that decides how a society works best, wherever blockchain ends up fitting in, interoperability will be the way it gets there. Because tomorrow, someone will release a new sidechain; tomorrow, someone will release a new framework tomorrow, someone will release a new framework , and it will be better, and it will be exciting.

And the more we get used to swapping and updating parts of the system, the more we will continue to improve the system piece by piece. So, interoperability, enemies working together, is actually, I think working together, is actually, I think , the way to survive in this space and to drive it forward. Yes, I think it's very likely that it's going to be a multi-blockchain future. I think we 're already seeing it. I think, you know, whether it's shards on Ethereum or know, whether it's shards on Ethereum or , you know, a more heterogeneous mix of different types of blockchains, I think it's going to be all of the above.

I think there's a lot of value. You know, the value that Ethereum can provide a sort of first main chain, so to speak. And whether that's like a settlement layer, and whether, you know, it's going to have maximum security, or whether it's just like this, like a master clock that everyone else is a slave to—it's more of a clock than anything else . There are a lot of interesting architectures you could build, but I think there will definitely be a lot of different blockchains connecting to each other, and we'll have to see what the right architecture is for that. I would say that interoperability is difficult.

That's why it's very difficult to create solutions, and we operate two protocols in production. One on the PO network, where the native token can be encapsulated in Ethereum, and we created that because we thought that on sidechains, it's quite difficult to access liquidity from centralized exchanges. Well, actually, when centralized exchanges connect sidechains, it's a form of interoperability protocol between one network and another. We wrapped our native token and moved it to the main network, and after a year of working with this bridge in production, we saw that it 's usable. It all sounds like problems and...

that it be included on more exchanges, but it's difficult, right? Also, it's a new attack surface, and the networks are different. And some theoretical interoperability problems are still unresolved, right? For example, the oracle problem is unresolved oracle problem is unresolved , right? The finality of chains , right?

The finality of chains —all chains, most chains, have probabilistic finality. Only private and enterprise chains have instant finality, and we will see some, like some chains with instant finality that will be based on proof of stake, but we've never seen interoperability protocols between these chains. And also an issue that many people don't think about in this area is the legal aspect of interoperability because when you think about interoperability between two chains, it's basically an exchange for, say, a pair of tokens, right? And it 's quite easy to not comply with regulations, especially US regulations. And that also prevents many types of protocols from being developed.

For example, if Alice can send funds to Bob across chains can send funds to Bob across chains , it will most likely require KYC on both sides. Otherwise, on both sides. Otherwise, how Will the protocol differentiate between US and non-US taxpayers? That's very important, right? That's why we designed our protocols to be self-transferring, right?

So, Alice can only send funds to Alice. And the last thing I want to add is that when you think about interoperability, developers and users will think about something else. For example, a game called Everdragons migrated from Ethereum to POA because POA has faster transactions and cheaper execution. And then they realized there aren't many users on this network, right? And they thought, "Yes, let's build another bridge to Tron, right?"

"Because Tron has a lot of users." And they built one more bridge, and this game has two bridges, one from Ethereum to POA and one from POA to Tron, and you can move your dragon from either of these networks and you can trade them. You can play on different networks. And that's what the developers built because there was demand for it, right? We thought, " demand for it, right?

We thought, " Yes, we need to add more liquidity. We need to make the tokens transferable." But game developers need to say, " game developers need to say, " Oh, we just need players, Oh, we just need players, right? And players exist on other chains. Let's just take this bridge to another chain and allow people to play other games."

Well, I think games are the future of interoperability. Sorry for the long answer. If I simply add, yes, I agree that interoperability is very difficult. We've created Hyperledger Fabric, but to do that part of interoperability, you have to understand the security properties, the validation mechanism, and many other things. But I think one thing that worries me about interoperability is where these layers are built into layer two.

We are building rather cumbersome interoperability mechanisms. And I wonder if we need to go down a level to a low-level protocol. I know that the Interledger Protocol exists. There are several protocols, our protocol, yours, but standardizing this and having a seamless way to conduct transactions is very, very difficult because the consensus is different, the security properties are different. And I wonder if we'll ever be able to achieve it.

I think one of the most important architectural decisions you have to make is what dependencies you are going to assume. And I think you're absolutely right that, right now , each type of layer one protocol lives like an island, you know, on its own. And I think it's only because we're at such an early stage in building this infrastructure that it's a huge risk to assume a dependence on someone else. But you could imagine that in a few years, you know, when the protocols really prove their worth, then perhaps assuming a dependency will be a reasonable option. Yes, I think we have to be willing to take that risk, willing to take that risk, right?

I believe the best way to take risks is to allow ourselves to be open to criticism, to be able to understand that Mainframe is open source. We have it out there. Everyone can sit down and analyze which part of our system is the best and which isn't, and help us manage risk through crowdsourcing. I don't pretend that I'm going to come up with the best ideas for the best protocol. Every day I learn some kind of new thing that I could integrate into the system, and I've learned a million of them in the last 48 hours I've been here.

So I think it's risky, and taking that risk means being open to criticism and being able to understand how to get the most out of it . Brilliant. We arrived just in time, so thank you all for listening and thank you for being here.