ScalingNOW! Interview 5: David Knott from OmiseGo on using Plasma MVP NOW!
There are a lot of projects focusing on building a scaling solution for Ethereum NOW! Each of these projects has their head down plowing forward with their solution and most don’t have time to communicate their solutions. We are pulling them out of their dark dev caves so that we can all understand our options for launching our DApps ASAP.
Using the Plasma MVP could be a fit if you are just starting your project and have a plan for how to get the tooling you need. If you are an established project, you can either build an app specific child chain now or you can wait until plasma constructions are able to support general state transitions; aka an EVM Plasma chain.
Once EVM Plasma chains are up and running, it’s a very promising solution and a more secure sidechain strategy than all the other bridges we have looked into because you can exit (withdraw funds) from a chain with a misbehaving validator within a set delay time . As long as you have root chain availability and are paying attention you have the same security guarantees as the root chain itself.
To use Plasma MVP, you need to create your own UTXO blockchain and build the functionality you need into the infrastructure of your Plasma chain. There are currently no blockchain explorers or other tooling for Plasma.
Plasma MVP achieves scaling through compaction. You combine a bunch of UTXOs to create a UTXO set. Then that is crunched down into a storable state. This allows you to increase efficiency when tracking the state of a chain.
To prove a UTXO was created at a given block, you submit a merkle root of the UTXO set (the small restorable state) to the root chain smart contract. If you want to get your funds back, you prove the UTXO is yours, wait a challenge period, and are able to cash out from the root chain smart contract.
Plasma MVP uses an app-specific sidechain that supports UTXO payments. Deposits onto the child chain are tracked via a smart contract on the root chain.
In V1, there’s a maximum of two inputs and two outputs, but other than that everything is how you would expect a UTXO chain to work. The inputs reference past transactions where value was transferred and they specify where in the child chain those transactions took place. The transactions also contain signatures from the owners of those inputs created in those transactions. The outputs specify the new owners and the amounts they’re going to own. The MVP is Proof of Authority (PoA) chain for simplicity sake though Plasma chains can use any consensus mechanism.
Here’s a potential issue and how it’s avoided: Say Alice sends a transaction to Bob, but the PoA operator decides to withhold that transaction. Now no one can exit because Bob doesn’t have access to the funds, but if Alice tries to exit she can’t because she’s signed off on sending the funds. To remedy this, transaction input owners must sign off on confirmations attesting that they’ve witnessed their transaction has been safely included in the root chain.
In Plasma MVP, if something goes wrong like the child chain going offline or invalid transactions being included, participants must exit within a set timeframe.
At first Plasma MVP is just going to be one Plasma chain connected to Ethereum. But eventually it will be multiple plasma chains; each relying on it’s ancestors for security, likely with Ethereum as the root chain.
We are funding the ScalingNOW! interviews transparently on the Giveth Platform. If you want to support the cause, please go here send some ETH or Token love. Any leftover funds will be split between the Web3 Foundation and Giveth.
Here’s David’s talk from the summit:
The insights and momentum gathered from this small gathering will feed into a larger public conference on scaling initiatives that the Web3 Foundation will organize. The initial details of this conference are still being determined but will likely take place in Berlin in late 2018. For more details, follow Web3 on Twitter, join the Web3 Riot channel, and join the ScalingNOW! Channel.
Griff: I’m Griff Green from Giveth, researching the scaling options for Ethereum DApps, specifically focused on scaling for my own project, Giveth. I’m here with David from Omisego. David, do you want to introduce yourself?
David: Hi, I’m David. I’m jazzed to be here. I’m joining from a dentist’s office in Bangkok.
Griff: It’s funny because I’ve been in Thailand for the last few of these, so it’s nice to switch places. Now I’m in Barcelona. Anyway, let’s dive in. Our audience is a technically competent audience. They’re competent devs working on their own DApp in the Ethereum space. They’re looking to use a sidechain as part of their launch strategy, and they want to launch ASAP. They’ve been working on this for a while. They might not understand all of the infrastructure behind Ethereum development, because who does? But they’ve been diving in for a while and they’re not rookies.
So you guys have a lot of things going on with Omisego, huge goals of basically unbanking the banked, which is really cool. But while you’re at it, you’re pioneering Plasma research. Which is where a lot of where this bridge tech’s probably headed. So the purpose of this interview is to take a deep dive into your MVP, and the current status of your technology, especially on what DApp developers could use in the next six months. So first off, what kind of DApps are the best suited to use your stuff, and when can people start using a DApp on a Plasma chain?
David: Plasma’s huge. The big picture vision is to track a general state machine, so basically a turing complete language on another chain — that’s still in the works. But what’s ready now is tracking specific applications. So if you have an app with a specific interface that you can detail and don’t need the flexibility of a turing complete language, I would say that’s where Plasma can really shine in its current MVP state.
Griff: Does that chain not have a full EVM attached to it?
David: Yeah. The Plasma chain in its current state doesn’t have an EVM, it just has the app-specific functionality. In the case of the bare-bones MVP, that’s just supporting UTXO payments, but it can be expounded upon to kind of fit a given application.
Griff: Can you talk about why you chose the UTXO model instead of the account-based system?
David: 100%. With account accesses, basically to be an approved account state, the simplest way is to take every transaction that either subtracts or adds to an account balance, and that can end up being a lot of transactions, and then you basically have to put all of them onto Ethereum. Whereas with UTXOs, because they’re basically finite, you can basically prove a balance with a single transaction. And so when you’re depositing or exiting, you basically only need to submit that single transaction to prove that at X time you had X money.
Griff: You explained this really well in the talk you gave in the decentralized exchange workshop video. Hopefully people can listen to that and then listen to this. I kind of see this as an addendum to that talk.
So you call your chains in Plasma child chains, because they’re born out of the root chain and in some ways subservient to the root chain. Can you give us an overview of how you imagine these chains working? I assume the root chain is the parent chain which is Ethereum, and the child chain is some kind of PoA chain with UTXOs?
David: 100%! You’re killing it, Griff. In the MVP, the root chain and the parent chain are synonymous just because right now we’re just dealing with one child chain. But down the road, the root chain will be kind of the final layer of security. In our case it will be Ethereum. And then you can have multiple parent chains. Parent chains are more of a relative term, just as you start stacking child chains on child chains on child chains, then you start having different kind of child-parent relationships. The reason they’re called child chains is because the child chains derive their security from their parents. In the case of the MVP, the child chain is deriving its authority from Ethereum. So if anything goes wrong on the child chain, people can basically prove a given state on Ethereum and retrieve their funds.
Griff: Very cool. So Mark Stanwick is asking, “How far out is a working implementation of an MVP?”
David: I would say very soon. At least what we’re focusing on right now is taking Plasma MVP and then extending it forward. We’ll start with a Plasma MVP and then add on functionality, so we’re thinking a lot about forward compatibility.
Griff: The chains are really cool, they have different models. How are the smart contracts structured on each side of the bridge?
David: The way it’s set up right now, there’s a root chain smart contract on Ethereum that secures a given child chain. The child chain doesn’t actually have smart contracts, the functionality is built in at the infrastructure level, which is a lot simpler to track. As soon as you get into opp codes, there’s so much more computation possible, just so much more complexity. The easiest example with Plasma MVP, just tracking UTXO payments, there’s one transaction format for the child chain, that’s much easier to track.
Griff: For sure. So it sounds like this is kind of a state channel solution. You move value to this off-chain thing where you do a bunch of value transactions, and then you end up with the solution — now give me real ether.
David: I would say there are some significant differences, but for first I have a question for you. What is off-chain and on-chain? Because I’ve thought about this a bit. Is the on-chain Ethereum, and everything else off-chain? A child chain is a blockchain.
Griff: That’s a really interesting thing. I guess it is on-chain, the thing is at least where it’s different in my mind is you’re kind of using someone else’s system, it’s a PoA network and you kind of have to trust the people running it, with Plasma and it’s exit strategy, you don’t have to trust, which is kind of cool to me. At least in application I think it’s kind of similar to what you do in state channels. Technically you don’t have to trust the people that are creating your state channel, you just have all these transactions and you’re holding the ability to exit whenever you want. And while the infrastructure is definitely different than state channels, this seems like the same kind of DApps that would kind of consider using a state channel solution would actually be more suited to using the Plasma MVP, than maybe a DApp that wants to use a sidechain that has an EVM.
David: Right now I would definitely say that’s the case. For most DApps you would want to build your functionality in the infrastructure level. Very few DApps are complex enough to need a turing complete language. It completely depends on what you’re looking for. For me, the appeal of Plasma is where it’s going is a lot more general purpose.
Griff: That’s very interesting. So basically if you want to use Plasma MVP right now, you could create your own blockchain that does exactly what your DApp needs right now, and that’s it.
David: Which for most projects will be good enough. The scaling pinnacle is EVMs within EVMs within EVMs.
Griff: EVMs all the way down. You actually seeded me with some questions, so I’m going to ask them. How are you dealing with signatures that are 15 seconds apart, especially from a UX perspective? And why do you need two signatures that are 15 seconds apart?
David: 100%. So in the Plasma MVP, you would send a transaction and you’d need to sign that, and you also send a confirmation. The confirmation would say that the transaction you sent previously has been successfully added to the child chain, and that child chain block has been submitted to the root chain and is valid. This is super important for a bunch of reasons. The easiest example of why it’s important is if you didn’t have confirmations and just tried to use straight transactions, if the operator is a bad actor, say Alice send a transaction to Bob sending him 5 eth, then the operator basically withholds the transaction, and then the operator can start publishing and exiting invalid transactions, and Alice has no way to exit, because if she tries to exit, the operator can submit proof of a double spend on the root chain, because she did essentially did double spend it on the child chain. And Bob can’t exit because the transaction was never included in the child chain, so he has nothing to reference. But with confirmations, basically up until Alice sends the confirmation, she can exit, and as soon as the Bob gets the confirmation, he can exit. So it’s a way of handling that safely.
Griff: And how do you deal with that in the UX?
David: There are a few ways. We’ve been thinking about it a lot. One way — you can delegate confirmations. Which is doable and helps on the UX side. I’m not a huge fan of it, trusting other people is a bummer. We’re trying to build trustless systems. The other way is to have it as in the background. So basically building a browser extension so that confirmation happens from the client but the user doesn’t have to keep a page open but just keep their browser open. Which is better but still not optimal. And the ongoing research is adding more rules into the mix and trying to eliminate confirmations. So that’s the solution I’m more pumped about, but we need to reduce scope.
Griff: You’ve got to reduce scope for the MVP. Two confirmations right now, not perfect, but that’s ok. What kind of UX do you have? What kind of DApp are you building as a preliminary DApp?
David: Right now the majority of my focus is on the base infrastructure level. We’re making the OMG network. The goal is to make it so that other people can build on the network. So we’re prototyping some potential DApps, some forward-facing DApps that could run on a Plasma chain that could show the functionality and what that would look like. Because right now, no one is familiar with what it would look like to build on a Plasma chain.
Griff: Of course, Plasma is just a cool word right now. It doesn’t mean anything other than that to me. It’s kind of this big mystery. So here’s another question you seeded me with that I think follows as well — in these DApps, is a general state transition coming to child chains, what complexities come along with tracking them?
David: A lot of complexities come just because there’s so much that can go wrong, and the amount of computation that has to be done is so much more. The greatest complexity is tracking exactly where things have gone wrong. That itself is doable in most cases, but there’s so many edge cases that can occur. Right now the focus is messing with merkles and playing with state roots. But going forward we’re looking into other cryptographic techniques as well to better compact state and to be able to prove what went wrong and where on a parent chain.
Griff: Ralph Merkle is a real hero.
David: He’s the real G.
Griff: He is. That guy just made so much magic happen, we’re all living off of that. He doesn’t get enough credit in this space. You said you have some preliminary DApps you said you’re trying to implement. Are there other teams that OMG is working with or are they all internal?
David: We’re currently looking to collaborate. It’s still early enough that right now we’re still defining what the endpoints will look like. Down the road what that will look like is we’ll solidify the spec and then from there we can work on getting the infrastructure level to production, and we will also publicly release endpoints so that people can start building on top of us.
Griff: What do you mean endpoint?
David: I mean something that people can hit, so most likely an X format that people will have to formulate and sign their transactions before they send it to a Plasma chain, and if they don’t meet that format it just won’t work because that’s what it’s expecting. So once we clearly define the endpoints, the given transaction’s accepted the given functionality for the V1, then people can even preemptively build upon that and take advantage of Plasma.
Griff: How does the UTXO child chain bridge send information back to the Ethereum chain? It has to plant the merkle root to the parent chain, right?
David: 100%. So right now, for the Plasma MVP, what gets sent back to the root chain is just the hash. And that hash is, as you stated, the merkle root of all the transactions in a given block, so from that you’re able to prove all the UTXOs spent and created in a specific block. Every time a block is created, right now because it’s PoA, the operator submits that hash to the root chain, and then everyone who has value on the child chain and verify that that’s correct. If that hash is wrong or if they can’t get it to verify it, they need to exit ASAP.
Griff: What do you estimate the gas to be for the operator for every block?
David: It’s not that expensive at all. We’re still getting around a bit with optimizations, but it should be like a few thousand max.
Griff: So a regular transaction is 21k. So it’s maybe 50k or less?
David: I would ballpark it at 100k, but we’re still running optimizations on it.
Griff: And so 100k gas every block is the cost to the operator.
David: That’s not too bad.
David: Basically the way the blocks are set up right now, we’re using a fixed merkle tree, so if we want to make it bigger, you just kind of add a layer of depth to the merkle, and suddenly you have twice as many transactions. The real issue with that kind of scaling is we want people to hold and run the child chains and verify them, and as soon as you start having these crazy huge blocks with a bunch of transactions, a bunch of UTXOs, my laptop might struggle.
Griff: Well a Bitcoin block is every ten minutes, so there’s lots of transactions going through, it seems to work. It can probably work for a DApp.
So let’s get real. Let’s say Giveth wants to build our own Plasma chain. Because we do. That would be pretty exciting. Right now we’re on Rinkeby testnet, I already explained before the call what we do. I’m curious where would we start, how would we as a DApp build our own blockchain that would model liquid pledging? Can we walk through the steps of how I would do it?
David: Definitely. So the first step is understanding kind of Plasma MVP if that’s what you’re going to go off of, which is what I would recommend because it’s the now solution. General state transitions are soon. So really understanding Plasma MVP and then from there thinking about how you can extend it for your specific use case. So a lot of the principles, an easy one is if you’re doing prepares and commits and that’s where it gets its security, and also Plasma MVP uses a priority queue for exits, and so taking those ideas and a lot of them are still relevant for a lot of different applications. So for liquid pledging, you’d still probably want to have deposit functionality, but from there people build in the other functionality on the child chain and then you’d only take it back to the root chain when you basically want to give the money or value to someone outside of the system. If you got the people who you are giving the value to on the child chains, you could create a whole ecosystem on a Plasma chain, which would be awesome, because the transactions fees, people would deposit, and as long as everything works, it would stay on the child chain.
Griff: I guess that’s one of the big issues — if there’s an authority. But I guess with a DApp the authority is the DApp team. If there’s a problem and the DApp team is dishonest, everyone exits the chain and escapes, and the DApp is over, but of course it’s over if the DApp team is dishonest.
David: That’s definitely true. Right now Proof of Authority is good because it’s now. Transitioning to Proof of Stake is not insane in terms of having a proof of stake contract on the root chain, maybe something along the lines of Casper FFG running as the consensus mechanism and kind of just following that on the child chain. And so I definitely advocate for V0, V1 proof of authority but then switching to proof of stake ASAP. Because you’re right, for DApps, if the DApp team is dishonest it’s horrible, but there’s a lot of way that people can get really creative especially if they control the consensus model in terms of quietly screwing people over, just fiddling with things just a little. It’s still scary.
Griff: How do you expect people to check? They’re running their own node or something, you have to have people run a node to use your DApp effectively?
David: Realistically we want people to actually use child chains and so everyone running a node can do that, they’ll have the option of running the child chain and validate it, but they can also trust other parties to do that if they so desire. So what’s key for us is offering anyone who’s interested the optionality to check with 100% certainty that everything’s correct. But we don’t want to force that burden upon the end user.
Griff: No end user is going to want to run a node, that will never happen. Even going to these websites that are running a node for you, mining Monero or something, maybe you could pull off a strategy like that, but it wouldn’t really make people happy that every time they use their DApp that their computer processor is tied up.
David: Yeah we’re definitely thinking a lot about the security. I guess for me what will be super key will be having a certain threshold of users actually checking it, because I don’t want people — Omisego, I am a trustworthy person, but I don’t want anyone to have to trust that.
Griff: I don’t know, I haven’t met you yet. Maybe we’ll see when you get to Barcelona. But also I want to go back to trying to build, most of the DApp teams have a Solidity system. They have some kind of smart contract system. How would you take that take it to a UTXO blockchain?
David: First, with UTXOs, you’re probably going to want to do account simulation. That’s basically UTXO netting. So let’s say you have Alice and Bob again. So Alice basically keeps all her funds in a single UTXO. Let’s say Alice has 100 and sends Bob 5. And she basically splits it up, she gets 95, that’s her new balance. So Bob has 5. And then Bob does a second transaction, say he has 10 before, then he combines them and has 15. So basically it’s simulating as if they had accounts, and why this is awesome is it’s a lot easier for applications to deal with. And when it comes time to exit ASAP, it’s a lot quicker and cheaper to exit one UTXO that’s your account, then 1,000.
Griff: So the first step is to build some system. Because when Alice has 100 in a UTXO, she sends the whole 100 to Bob and gets 95 back, right?
David: No. When Alice creates the transaction spending 100, she creates two unspent transaction outputs, one with 95 to herself, one with 5 to Bob, so Alice always has custody of her funds. And I see that as built in behind the scenes. The end user should never have to worry about that.
Griff: Okay. So then when Bob sends a transaction here and gets some change. Sorry — I think of it as change, but you break it up and then you send it. So let’s say Carol decided to send Bob some money too, you want to be able to smash the 5 UTXO — we’ll call it OMG coin — the next 5 OMG that Carole sends, you have some kind of system that kind of squashes them together. And then everyone has one UTXO in their account.
Griff: So how do I model something as complex as a DApp on a UTXO blockchain?
David: So I would start by going through each function that you have in the Solidity smart contract. Basically there’s a good chance you can put that functionality in the child chain in the infrastructure level instead of the smart contract level. So it’s basically taking a smart contract and building the child chain infrastructure around that single or group of smart contracts if you’re dealing with multiple ones in your DApp.
Griff: I’m trying to think of this in Bitcoin because Bitcoin’s the UTXO structure I know. And maybe in the client they have some cool things like the child pays the parent. And that’s kind of something that you could model on a smart contract, but they have it in the client. Is this basically what you would do? You’d take functionalities in your Solidity contract and put it in the clients that are running the child chain?
David: Essentially, yes. For some, you’d add rules for the child chain. An easy example would be modeling an ERC20 token on a child chain. So basically, Plasma MVP, by just adding a currency field you can support ERC20 tokens as well as ether, which is cool. But if you wanted to create an ERC20 on a child chain, you could basically build that functionality in. So for a given fee people could send X information, maybe it’s like symbol and all the configs for an ERC20, they send that to a child chain, and then that gets created on the child chain, and then from then on that basically becomes a valid symbol for transactions, like typical Plasma MVP transactions on a child chain. Another example would be like if you want to add in a burn functionality to a child chain. Sure, you could send your UTXOs to a 0 address or some random address. That’s one way. But you could also implement burn functionality. So in the infrastructure, JSN-RPC, people could call burn with x information, and boom — you have burn. So that’s it on a super-simple level, but you can become increasingly more complex from there.
Griff: Interesting. The challenge here is if you build your own chain, you have to build your own block explorer and a lot of the infrastructure around that.
David: We’re 100% thinking of that. Right now there’s some solid block explorers for Ethereum, but given that Plasma is a baby, there are no block explorers for it. It’s something we’re thinking a lot about because if people are relying on the child chains, they need to be able to see the status of a given child chain at any time. The way to deal with this, I see it as standardization. As soon as you start dealing with app-specific child chains, there’s a very real danger of each project to not only handle a plasma chain but also handling all the tooling that you want for a blockchain. And so as kind of research moves forward, I’m really hoping that there’s a certain standard for interacting with plasma chains.
Griff: You say there’s a lot of good Ethereum blockchain explorers, but there’s not. There’s only Etherscan. It’s a really big problem. Etherscan is not open source. Any sidechain right now, we have to show people what’s going on. Especially when everything’s in alpha, you shouldn’t trust the DApp itself. You need that second-layer verification. It seems like a real challenge for me, at least for the MVP, for somebody to build a DApp-specific chain. What we do for liquid pledging is totally different than what a decentralized exchange would do.
David: In terms of Ethereum explorers, I more meant they exist, as opposed to plasma chain explorers which do not exist. It’ll be a super-interesting path. For MVP-type stuff, it would be great if people had a nice way to view it in the browser. It’s not critical to functioning. People are able to run and validate the child chain because that’s what security relies on, because then they’d be able to challenge and exit. Right now a block explorer is kind of future.
Griff: Well that’s really cool. The other big piece is doing the exchange. The other thing you could do is kind of what POA Network did, with these cross-chain crowdsales, where you actually make your currency native to this child chain, and you just have this deposit function as this ICO, and all of a sudden you have this chain that relies on Ethereum for its security, but boom here’s your security. The problem with that is how do you trade your currency. That’s where OMG comes in, I take it.
David: Liquidity is definitely something we’re thinking about. Because for trading to occur, liquidity needs to be plentiful. It’s a little more complex because people have to enter the world of plasma and child chains to kind of trade, basically.
Griff: This is really good, thanks so much for answering my tough questions. So we have Madgeco is interested specifically in things for OMG. So I’m going to skip those because this is not an OMG pumpfest.
David: That’s ok, there’s enough of those.
Griff: Mark Stanwick asks, “Can you talk more about the PoA security of the MVP as it related specifically to OMG?”
David: So basically POA is not optimal in terms of consensus, but in terms of getting something out there, it’s the least complex. By doing POA, it doesn’t have the sturdiness of a POS mechanism, but it doesn’t decrease security in the sense that if anything goes wrong, even if OMG was running the POA chain and they tried to act badly for whatever reason, basically they couldn’t do anything as long as other people are basically validating the child chain and as soon as the operator does something bad, you exit within a given amount of time.
Griff: And that means you have to be online checking within seven days, right?
David: Exactly, you have to check or there’s ways to set it up so that someone you trust can basically exit for you. So basically this is not giving anyone access to your funds but giving someone else access to basically leaving the child chain for you if you’re not interested in checking the child chain every seven days.
Griff: I think that’s a good delegate model.
David: It doesn’t really sacrifice security that much.
Griff: The worst case scenario is that everything’s fine and you exit anyway. Now we have Ephonedev who’s asking about Tendermint plasma. Will they run in parallel for some time, do you start with Tendermint and migrate to plasma, what is the relationship between Tendermint and plasma?
David: Tendermint is super cool, super versatile. The way it’s set up now, a plasma team is evolving in Bangkok. And then we also have a blockchain team in Poland which is working on Juante(?), which is basically a Tendermint-based exchange.
Griff: So you have a plasma team in Bangkok and they’re eventually going to translate PoA to Tendermint?
David: Right now we’re still playing around with the potential interaction between the two. Right now the focus in Bangkok is evolving the plasma specification and getting that formalized.
Griff: And Tendermint, I know in the Plasma calls, Tendermint’s there, Cosmos is there, and you’re there. Do you know if they’re doing their own Plasma research?
David: Everyone on the call is kind of at least for now doing kind of their own thing and then the calls are a wonderful opportunity to put our heads together and learn from the different niches that each project is carving out.
Griff: Elmar Devar asks, “What is the minimum fee a validator can set?”
David: This is for OMG staking tokens proof of stake. This is not directly related to scaling. I would say it’s an area of active research. Basically for different use cases, it makes sense to kind of do both essentially. I don’t want to say too much before it’s ready.
Griff: I’m going to answer this one from Ian Love, who wants you to explain merkle tree and why it helps plasma OMG projects. Ian, Grid+ wrote an incredible article on how merkle trees work, and if you read that article and then watch David talk in the decentralized exchange workshop, with those two resources you will have a complete understanding, better than any of us can do with words.
Griff: Mark Stanwick has the best questions. He’s awesome, keep asking questions Mark. “How would the average user go about validating a PoA chain. What would that look like?”
David: Right now we’re talking about it being a child chain status tracker. They’d run a program and be pinging the child chain endpoints, so like API endpoints to get the information they need to validate each block. So basically checking each transaction to make sure it has the necessary signatures, checking for double spends, all that stuff. And then if everything is good up until they have information, then they are basically safe to use it. If anything’s wrong, exit.
Griff: So they need to be watching the smart contract on Ethereum and be validating the blocks.
David: Basically validating the child chains blocks is awesome, but if another hash gets submitted to Ethereum because the hashes that are submitted to Ethereum are used to prove who owns what at a given time, it’s super important that those match the child chain blocks.
Griff: Ephonedev, who also asks great questions, asks, “Does plasma require Casper or sharding to be finished on ether?”
David: No. The way I think about it is they are super-complimentary, but they don’t require each other. So they are both kind of progressing forward. With sharding and plasma, the scaling potential is nearly endless.
Griff: Mark Stanwick asks, “Seeing as how these scaling issues have yet to be solved and are so important, do you ever feel overwhelmed with their size and scope?”
David: Yeah, so this is sort of a call to action. From an outsider’s perspective, at least when I was an outsider, I kind of thought that everything was being worked on by huge teams, and everything was super organized. And these projects with lots of money on the line, had super organized people constantly working on solutions. This is not the case. I hate to break it to everyone out there, people are working very hard on solutions, but there can always be more people. There are so many different problem spaces involving scaling and other kind of blockchain problems that need to be researched solutions that are waiting to be found. So yeah. Overwhelmed sometimes, but join in and I will feel less overwhelmed and we might be able to solve some big problems a little quicker.
Griff: Join the scaling party. In fact, we’re having a few scaling parties in Barcelona. I belive you’re going to make it.
Griff: We’re going to do an event on the 5th that’s really just for the scaling solutions, people who have scaling solutions so that they can do kind of the same thing that happens on the plasma calls, kind of the brain meld so you can talk to the state channel guys, the bridge chain guys. So if you’re working on any scaling solution, reach out to me so I can get you in on the 5th, that’s invite-only. But then on the 6th, DApp teams are invited to come and interact with scaling solutions, they can come and talk to you, you’ll have your own little table, and they can ask you, “Hey, what do I need to do?”
David: I get a table?
Griff: Yes! It’s a rental.
David: I can’t keep it. Okay, thanks for telling me that now.
Griff: And then we’re actually doing a cool 777 launch party after that. So after two days of blowing your brain out with talking to all the geniuses talking about scaling, you can have some beers and watch Jordi make magic happen when he launches the first 777 token. So if you guys want to come to Barcelona, reach out to me in the Riot channel. Thank you so much for the call.
Griff: One more question — Mark has one more. “How can someone with a non-development background contribute to scaling research?”
David: I got this. I would say implementation is very developer-heavy. Mechanism design definitely requires logic, but you don’t necessarily need dev skills. So I would say, it really depends how you learn, but going to events, talking to people smarter than you, reading a bunch of papers. How I think about research is you have a toolkit of some cryptographic stuff, some mechanism design stuff, and the more you learn, the more you can put stuff together to make stuff, so learning as much as possible. And you don’t necessarily need to code anything, you can kind of just think about it in a theoretical level, create specks and stuff.
Griff: I’m not a developer, I feel like I’m doing something that’s helping.
David: You can bring people together like Giveth does.
Griff: Good old Giveth, bringing people together. Thanks so much for your time, David. Enjoy Thailand, I miss it already. Glad your mouth is less numb now. I can see that it improved from when we started this call, so that’s good.
David: I’m pumped for Barcelona, it’s going to be fun.
Griff: Thanks man, thanks for joining us.
Found this helpful?
Please send some ETH to support ScalingNOW! and enable us to continue reviewing scaling solutions! 💙
Still want more?
Join our community: by tackling interesting problems like this one you can help us make the world a better place!
- Find us on Riot or Slack
- Discover our Site and Wiki
- Fork our code on Github
- Follow us on Medium, Facebook, Twitter and Reddit