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 the DApps ASAP.
In our third Scaling NOW! interview, Griff Green from Giveth talks to Jason Teutsch and Sina Habibian from TrueBit to get the deets on their solution to offload computations to a decentralized computer network:
Solution is best for: DApps with heavy computation requirements and also DApps that want to do cross-chain transactions with UTXO chains, especially Litecoin or Dogecoin. If you need to verify another chain’s proof of work, if you need to tally up some votes among validators, or if you need to verify signatures, TrueBit is something to follow closely.
Solution issues: Need to have a DApp that can afford paying a reward for these computations. The solution may not be ready for 3-6 months.
Summary:
TrueBit is creating a way to offload DApp computations to a decentralized network of computers.Here’s how it works:
TrueBit will have one smart contract deployed on Ethereum at a single address. The API is simple. You use the function “Create Task”. As an input to this function, you include three main pieces of information:
- The program you want to run. This could be in WebAssembly bytecode, some GeneralAssembly, C, C++, or Rust.
- The inputs you want to pass into your program. For example, this could be an array of votes in the case of a vote-tallying program, or the plain text block header fields in the case of the Doge-Ethereum Scrypt hash program.
- A reward for whoever solves your task.
The task is then performed by the TrueBit network, a network of computers who run the clients locally on their computers and are configured to listen for events on the TrueBit contract. When they see a new event get created, they run the task locally (completely off-chain), and post the result back to the contract along with a deposit.
To guarantee that the solution is correct, anyone in the network who observed the task can challenge the solution. They can post their contradictory solution along with a deposit. So now the contract has two conflicting answers and it starts playing a verification game between the solver and the challenger.
The verification game involves playing a binary search game; starting from time t=0 they first started running the program in a blank state virtual machine to time t=T where the program ended and the solver and the challenger got conflicting results.
They compare the Merkle root of the the entire state of their virtual machine at every step of the calculation until they find where their answers differ.
The point of differentiation, the single op code, is then run on-chain. Ethereum miners execute the code and come to consensus on the result. Whoever disagreed with the consensus solution—be it the solver or the challenger—has their deposit slashed.
So essentially, you as a DApp developer can, regardless of the gas limit, execute any computation and get the results back in a decentralized trustless way.
ScalingNOW! IRL Gatherings:
Web3 Foundation and Giveth are working together to create an in-person gathering on March 5 & 6 of the top devs working on scaling solutions, as well as the DApp developers that rely on these solutions. Day 1 will be invite-only for select devs working on immediate scaling solutions to share their insights amongst one another. Day 2 will be open to DApp developers who submit a (super quick and easy) application on what they are building.We encourage all interested DApp teams to apply here.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.
Do you want to support ScalingNOW!?
We are funding the ScalingNOW! interviews and subsequent Barcelona gathering transparently on the Giveth Platform. If you want to support the cause, send some ETH or Token love to 0x9cb8921aa376219950ba134c15d8f5ee2769c599. Donations received will cover the costs. Any leftover funds will be split between the Web3 Foundation and Giveth.Related links:
TrueBitTrueBit GitHub
Sina’s Twitter
ScalingNOW! chat on Riot
ScalingNOW! YouTube playlist
Application to join the ScalingNOW! Gathering on March 6 in Barcelona
Giveth
Transcript:
Griff: Thank you for coming to ScalingNOW! I’m here with Jason and Sina from TrueBit.Jason: Hi, I’m Jason Teutsch. I’m in the blockchain business, I love blockchains. I started a project called TrueBit, which is a scalability solution for Ethereum. I’m excited to chat about it today.
Sina: I’m Sina, I’m a core developer at TrueBit. I’ve been working on the protocol with Jason and actually build the thing.
Griff: Thank you guys. I love the work you’re doing. You’re working on a lot other than TrueBit, Sina especially--you’re bouncing around, talking to every Ethereum dev everywhere about pain points. And one of the biggest pain points is scaling, I’m sure you’re hearing that everywhere. And so that’s a little off-topic, but the main topic is what we can do to scale. And TrueBit is a super-cool project that has a lot of interesting solutions. There is a bridge solution and something you can do to take calculations off-chain. And I want to talk to hear about the project scope in general, but I really want to focus on the applications that are useful in the next 3-6 months for DApps to scale on Ethereum. Our audience is really high level DApp devs.
Sina: To give you some context, TrueBit is an on-chain/off-chain solution. It’s kind of a hybrid thing that basically allows you to run computation off-chain and get the results back in a verifiable way.
Jason: So the idea is to scale computation. Many scalability solutions are focused on transaction throughput. We’re focused on really big transactions. We’re happy if we get one really big one. So you can think of it as a computation oracle. It can fit on top of Ethereum without making any changes to the underlying machine, and it could probably run other systems as well.
Sina: To get into the details of how a developer would actually interact with the protocol, TrueBit will have one smart contract deployed on Ethereum. So it will be a single address. And you as a developer or you as a smart contract have a computation that you can't fit within the Ethereum block gas limit.
In the case of the Doge-Ethereum bridge that we just demoed a few days ago, that computation was calculating the S scipt hash of some plain text values. Or in the case of Aragon, we’re talking about potentially building a scalable way to tally up votes. In that case, it would be you have a giant array of voters that you want to iterate over, and using some function to calculate the results. And again, you can’t set that in the block gas limits.
So how you would use TrueBit to do this is you have one smart contract, and really it has one function that you’d use. So the API is really simple. The function is called “Create Task,” and you’d call it with the first argument, the actual program you want to run. So in the most generic case this would be some bytecode. And specifically some WebAssembly bytecode, some GeneralAssembly C, C++, or Rust program. And the next inputs, the next function arguments, would be the inputs you want to pass into this program. So the array of voters, or the plain text in that script hash. And you include some reward. This task gets created inside of this contract with a reward attached to it for whoever solves it. And at this stage there’s a TrueBit network. And it’s basically all these computers running the clients locally on their computers, that are configured to listen for events on this contract. They see a new event get created, they download it, run it locally—completely outside of the network, and post the result back to the contract, along with their own deposit. So at this stage you have a solution and deposit from the solver.
To cut this short, basically the next stage of this protocol is anyone who observed this happening can challenge that original solution. So they can say, “I also ran this thing locally. I got a different result, and I’m going to post my contradictory solution along with a deposit. So now the contract has two conflicting answers and it starts playing what we call a verification game between the solver and the challenger. And a verification game involves playing a binary search game starting from time zero when you first started running this program in a blank state virtual machine to time 100 where the program ended when the solver and the challenger got conflicting results. And basically the original solver needs to defend their solution by providing their state root from the entire state of their virtual machine at the halfway mark, at the 75% mark. Basically the challenger forces them to narrow down the scope of the computation to the point where both the challenger and the solver agree on the state of the virtual machine on one step, so you know after 10,000 op codes have been run, and then they both run this single op code, but they disagree on the result. So the scope of the computation is narrowed to the point where that single op code is run on-chain and you basically get all of Ethereum miners executing it, coming to consensus on the result, and whoever disagreed with that — be it the solver or the challenger — gets slashed.
So that’s the general outline of the protocol, but what it boils down to is you as a DApp developer, you can have a piece of solidity code, you could have some WebAssembly code, you can basically, regardless of the gas limit, execute it and get the results back on-chain.
Griff: Which is really cool. I’m sure that will help a lot of DApps. I’m interested in breaking that down a little bit. Can you move that into actors? So there’s the DApp that puts a fee on a calculation, and then there’s the claimant? Can you say all the actors?
Jason: I guess your DApp, with TrueBit, you have a task-giver who creates the computational task. That would be your DApp, presumably. And inside of TrueBit, which is invisible to the DApp, you have your solvers and verifiers that make sure that TrueBit gives the correct answer, so they use the incentive coming in from the task giver to make sure that TrueBit outputs the correct computation.
Sina: So there’s the task-giver, there’s the solver, and then the people who are watching the task in a passive way — we call them verifiers. And as soon as one of them decides to actually submit a challenge, we call them a challenger. So task-giver, solver, verifier. In the case of the Doge-Ethereum bridge, it was kind of a variation of the protocol, where the task-giver and solver were actually the same person. So this person was saying that if the task is to calculate the script hash of these plain text fields, and here’s the actual final value of that right away. And then they open themselves up to challenges.
Griff: That’s pretty cool. And you guys are doing this Doge-Ethereum bridge. How close are we to getting an EVM bridge? Like a bridge between the main Ethereum bridge and a sidechain?
Jason: Well we already have some of those, like Rinkeby, Kovan—
Griff: But they’re not bridged. The idea is like you could have an asset—let’s say, a token—on one chain, and then lock that token up somehow and bring the value to another chain. Do some calculations over there, do DApp development over on that chain, and bring it back over.
Jason: It’s not like Ethereum and Ethereum Classic and a piece relay—we’re talking about something more like Doge-Ethereum. I guess maybe it’s important to distinguish between relays from what we’re doing. It’s not like a trustless exchange. It’s not like I’m trying to trade my Dogecoin for Sina’s Ethereum. We actually want to take the Dogecoin off the Dogecoin blockchain in one sense and teleport them onto Ethereum and use them inside of smart contracts or whatever and then be able to send them back. That’s what a two-way peg is about. It actually gets easier if you have smart contracts on both sides. Well, maybe “easier” is relative.
Sina: So the first distinction Jason makes is atomic swap vs. relays. So we’re talking about relays in this case. So, in some sense, connecting two EVM chains has way more flexibility because you have smart contracts at both ends, whereas in the Doge-Ethereum you just have UTXOs in the Doge side. But the thing that’s interesting is, when you’re connecting two chains, the main chain needs to have a way to verify that a certain block header occurred on a legitimate chain in a trustless way. Or in a way that’s not interactive in a way.
So in the case of the Doge-Ethereum bridge, what we leveraged there is that Dogecoin is a Proof of Work chain. So as long as anyone submits these block headers to the Doge relay contract on the Ethereum side, and you’re kind of tallying up the proof of work accumulated on each, you can over time pick out which is the canonical chain. And once you have that, after that point, it’s like someone submits a transaction on this side where they declare that they want to move their coins over to the other side, and the relay contract can check that this transaction actually occurred on the real network by checking the Merkle proof of it from one of these known block headers. So if the other EVM chain has an objective way where you can use some cryptography of proof of work to verify what the legitimate chain is, you can very directly implement the same ideas. Otherwise, if it’s a Proof of Authority chain, you need some kind of social consensus built in this Ethereum relay contract.
Griff: And that’s the thing—you guys have this Doge relay contract. It seems that if you just switched it for one that’s more customized for—you could do the same thing, right? You could have block headers come in from that other blockchain and have them be verified there.
Jason: It actually simplified things considerably because you no longer have to check the Dogecoin proof of work. You might have to check some signatures one the authority chain, but generally it substantially simplified the construction.
Sina: You’re trusting the authority, so if you see their signature on a certain block header, then you can trust that it actually happened on the EVM chain. So TrueBit is kind of part of the verification mechanism. The way it’s used in the Doge-Ethereum bridge is to verify the proof of work. In an analogous way, if you’re building one of these bridges, TrueBit could be used to, you know, tally up the votes of some validator set, or to check the signatures of the authorities for anything that’s too computationally intensive for the actual relay contract to do on its own.
Griff: Are there any points of centralization in your current setup that you’re eventually going to remove as you scale up?
Sina: Before we move on, we’re collaborating with another team on the Doge-Ethereum bridge that you should also talk to. Oscar from Coinfabrik, Oscar was recently at RootStock before. They also have some interesting insights on how to build these relays.
As for points of centralization — like we mentioned, this Doge-Ethereum system is kind of a stripped down version of TrueBit. It doesn’t have the full incentive structure that’s described in the whitepaper. You’re relying on both the claimant who’s passing in the headers and the verifier to do this altruistically without expecting to make money from it. So that means that there’s no gravitational force that’s pulling people into this system to actually check that everything’s running correctly. But I don’t see anything pushing it towards centralization per se. So anyone’s welcome, especially since the tasks are defined up front, and it’s a simple computational task of hashing some value. As long as there’s one honest node node running in the entire network, checking these tasks, it will work.
Jason: I want to emphasize that we’re specifically talking about the case where you’re moving Dogecoin onto ETH. We haven’t talked about how to move them back home, right? The one way that we’ve done, RSK used what they call a federated peg, which means that you have five guys who you really trust and they’ll take care of it for you. So that is one option.
Griff: They have seven.
Jason: So in theory you can do it with seven as well, I don’t see why not. I don’t know if it's better or worse, you can argue either way. Let’s list a few ways where you could do the other direction. The most secure way would be to get the Dogecoin miners to all treat the Ethereum blockchain as authoritative. And they would be watching the blockchain and say, “Okay, this ERC20 token or WOW token got burned on the Ethereum side. Now it’s time to unlock a Dogecoin.” And you would have an opp code to unlock. So that would be super-secure, it looks sort of bulletproof, but politically it might not be the easiest thing to implement. And then you have some other ideas.
Sina: Another idea is, this is an interesting idea that can be extended to other relay constructions. So basically the way you got into the Ethereum side is some Dogecoin holder sent a transaction to some UTXO, encumbering that money with someone’s signature/key. And then the relay contract has been configured up front to treat any money at that address as like, the intention is to move it to this other chain. So you can verify the proof, you mint the ETH, the WOW tokens, give them to the person, they move it around, and then at some point, someone burns those coins when they want to move them back. When they want to return it back, they burn those coins. And it’s that original UTXO recipient’s responsibility to send the money back to whoever that person is. In the case of federated peg, this UTXO on the doge side is a multisig. And you’re relying on these people being reputable, in different jurisdictions so they can’t all be coerced, these types of things. But at the end of the day, you’re trusting them. And you don’t have any real security against them going rogue.
Griff: But inside the relay, let’s say I have the Doge bridge and then maybe Giveth wants to bridge to Rinkeby. We do, we want to bridge to Rinkeby. Would the verifiers that are in the TrueBit protocol be doing all of these tasks?
Sina: It depends on how you define the task. One way you could make this construction more trustless is if you make the person operating the bridge, so whoever's address on the sidechain people are sending money to, if you make them deposit some stake into the relay contract. From then on, they have some skin in the game. The money transfers, the Bitcoin transfers over, they’re in this network, and then at some point someone burns some of their tokens, indicating they want to receive them back on the original chain. Now the way you’d make this more trustless is the token burn happens and the relay contract starts some kind of timer where, like, 50 blocks, and within those 50 blocks, it expects to receive a Merkle proof from the other chain that the operator sent them their coins. And since this relay already is acting as a lifeline for this chain and already has all the block headers, it can fully verify that this transaction happened. So if it doesn’t see this happening within the timeline, it slashes the operator. On the other hand, if the operator is just going rogue and sending themselves money on the other side, someone can take one of those transactions and provide it to the relay, and prove that there was no corresponding token burned, and prove that this transaction was malicious, and get the operator slashed again.
So I don’t know exactly how it would fit into connecting Ethereum and Rinkeby, say but it’s one way to make the operator deposit stake into the Ethereum smart contract and then keep them honest by expecting them to provide proofs, or expecting people to provide counter-proofs that they were dishonest.
Griff: So that’s not really ready yet, right? Right now everything is altruistic?
Sina: Yep.
Griff: But if you kept that altruistic model, which I think would work for a DApp to do a sidechain, something along those lines, would it be easy for them to upgrade as the game theoretical stuff you guys develop around these slashing conditions evolves?
Sina: One of the design decisions for TrueBit is to abstract away everything that’s happening. So as a developer, you only care about that you send the task in, and at some point you get the result back. And how it’s incentivized and who’s actually checking it and how many people are doing that is all kind of abstracted away from you.
Griff: Well that’s cool. Is the TrueBit protocol it’s own network, and people that are using the protocol for different bridges or different calculations, would they all be using the same group of people? Or would each specialized calculation, like the Doge-Ethereum bridge, maybe the Rinkeby-Ethereum bridge, maybe off-chain voting, would those all have to have their own little networks of people?
Sina: There would be one network. We can think of it from different people’s points of view. From the DApp developer’s point of view, like we said, the system is just one on-chain contract that you send tasks to and that calls you back at some point in the future with your result. So that’s all you care about. You don’t need to worry about getting a network online or incentivizing computers or miners or anyone to take part in this. So that’s from the DApp developer’s point of view. On the other hand, let’s say you’re someone who has computational resources and you want to join this TrueBit network and basically have some earnings on computing tasks. From your point of view, your clients would be configured to listen to this one contract, the one TrueBit contract on-chain. And as these tasks come in, the actual description of what the task is is in the function call. So it’s some WebAssembly bytecode, or it’s an IPFS hash where you can go and download the program. So the idea is that the local interpreter you have running inside your client basically goes and gets this program, runs it locally, and posts the result back. In the case of this Doge-Ethereum bridge, that’s generally how the program will work. Since it’s WebAssembly bytecode, it works for any application.
Jason: It was a pleasure, I have to take off.
Sina: Since it’s any GeneralAssembly bytecode, it’s all one network.
Griff: The people verifying that data could filter for that bytecode for the ones that they care about, or would they not even have to do that? Could they just process all of them?
Sina: That’s an interesting question. At some level, if you allow people to filter what they execute and what they don’t, that kind of opens up certain attack vectors. The model we’ve been exploring, you pass in some WebAssembly bytecode, and an award associated with it, and it’s kind of similar to Ethereum in that each op code is metered at a certain price, so there’s the equivalent of like gas. And then beyond that, someone who's computing the task shouldn’t really care what it is. But in some other worlds, there’s certain tasks that are more suitable to certain types of computers. Like if something relies on GPUs. You might want to allow people to self-select into certain discrete buckets of tasks. But these are details that we’ll get to in the future.
Griff: So in the implementation that you have that people can use, what state is that in, and how can people start to play with it?
Sina: We’ve been inspired by the people at Protocol Labs to build something modular. So instead of building one system that goes live all at the same time, really try to push it out in pieces that work separately. Thinking about it in that way, there’s a few discrete things. One of them is what we call the “dispute resolution layer,” or the verification game. So this is a contract that plays out this back and forth binary search between a solver and a challenger and eventually narrows it down onto one step. So that system can exist regardless of incentives and regardless of what virtual machine these two people are running. Then there’s another layer which is the virtual machine itself. So this is what the clients run locally. You also need to implement this thing on-chain because, for the final step after you've narrowed it down onto one instruction, you actually run the same code on-chain. So this piece can be a WebAssembly interpreter which is what we have right now, running both and Solidity for on-chain and in another language off-chain. But if people want EVM, for instance, or if they want some other kind of virtual machine, you could also build out different ones and plug them into the whole system. And then the final piece is the incentive layer on top of it. One task came in, how do you incentivize to post a solution, for verifiers to actually watch this contract and participate? There’s multiple different designs we’re looking at over there. That’s kind of the piece that’s most research-y right now.
Griff: And very cool, by the way. I love the idea of making people send in false data to be challenged.
Sina: The TrueBit protocol described in the whitepaper has this sequential nature in which, once someone posts their original solution, others can challenge. And these challenges can play out one by one. But we’re exploring an alternative protocol. If you think about it, both the solver and the challengers kind of did the same thing. They both downloaded the program, ran it locally, got some results, and posted it to the contract. One idea is what if you get all these people to submit their solutions at the same time? And then the contract dynamically sees if there’s only one solution or if there’s clusters of different solutions, and you could get these different people to play pairwise verification games with each other, tournament-style, and knock each other out. You get better timesiness guaranteed. The whole thing resolves way faster.
Griff: If there’s a 51% attack, that doesn’t matter, because people are either right of they’re wrong. If 90% of the network is all trying to lie, all it takes is one honest node to make sure the truth comes out.
Sina: One way we’ve been describing TrueBit is a computation oracle. But you’re not relying on some outside party to be the judge of what’s correct or not, your final judge is the Ethereum network. So as long as you trust that Ethereum’s running securely, you only need one honest participant. And also to give credit where it’s due, this multiple solvers at once approach was really pushed along by Zach Lawrence from 1protocol, who’s also been really awesome to work with.
Griff: I know Zach, he’s a good guy. He worked with Slockit. He’s a genius, for sure.
Griff: So here I am, Giveth. And I’m trying to bridge to Rinkeby. Do you think I have a chance of using anything in TrueBit in the next 3-6 months to help me do that? Right now there’s a lot of centralized bridged solutions where you have to have a multisig somewhere around. And I like that, it’s fine, and I don’t mind starting out with altruistic nodes because, hey, we’re an altruistic platform. But it would be really nice to have a centralized peg between the chains. What are the odds of that happening for us?
Sina: I think TrueBit could play a part in doing any kind of verification in that bridge. So if you need to verify another chain’s proof of work, or if you need to tally up some votes among validators, or verify signatures.
Griff: That’s what we would probably do—verify signatures. At least from what your description is. I would say, hey, let’s verify the the multisig that is receiving ether. We’re going to have ether sent to an address and it goes to a multisig and then that multisig will only send ether out if stuff on this other chain happens the way it’s supposed to happen. And that can be done by a contract on that chain. So being able to have this extra verification layer that’s kind of like a third-party certification that can verify the bridge is honest, that would be really valuable. And honestly I think it would be pretty valuable to a lot of projects that are looking at sidechains.
The time issue is what I’m really interested in. How soon do you think you’re going to have a network of people verifying?
Sina: Back to the different pieces of the engineering puzzle, the WebAssembly off-chain and on-chain interpreters are built already, they’re on our GitHub. But it’s the V1, unoptimized version. The binary search layer, the verification game layer, we’ve implemented fully for the Doge-Ethereum bridge, but again it’s kind of custom to that solution, and so we need to build a more flexible version of it. In the beginning you could even run it without incentives, so you could say, “Because this whole scheme is altruistic, there’ll be people checking it,” and you could get people who care about the Giveth platform to be these validator nodes.
Griff: We can pay them outside of the protocol, we could give them .1 ether/month for verifying.
Sina: Totally. So I think within the next six months, in the next three months even, we’ll have something. This is what we’re working on every day. Another interesting thing we’ve been thinking about is how to best push TrueBit forward. There’s two different approaches. One is to really go for the generic protocol from the beginning, build a WebAssembly virtual machine, the dispute resolution layer, and put it out there. And write some really good documentation and get people to start integrating with it. Or, and we’ll probably do this in parallel, really pick out individual use cases that could be demonstrative and could help us flesh out different pieces of the protocol, and build them in a more hands-on one-by-one. So the Doge-Ethereum script verification is one of these use cases. One of the next ones could be this carbon voting in Aragon. So that’s the kind of the approach we’re thinking of taking right now.
Griff: That would be pretty cool. I did this interview with Parity and POA Network and there’s a few other sidechain groups that I’m going to talk with, and a lot of them have these centralized pegging solutions. So a third use case would be really awesome just to be a verifier of some of these other bridges that are jumping in and out of the Ethereum protocol. But we’ll talk about that in March. Hopefully you guys can come to Barcelona March 5th and 6th. On the 5th we’re trying to get everyone together who are building scaling solutions just so they can bounce ideas off of each other. There’s so much learning that can happen if you get outside and learn what other people are doing. So we’re trying to get everyone together to speed up the process and make it more efficient. On the 6th, getting all the DApp teams to come and pick your brain about how they can use your solution.
Sina: That sounds awesome. I don’t know if I personally am going to be able to make it, but Robbie will be there. I totally agree that proof of authority chains are one of the most practical ways to scale the network in the short term, especially I forget who came up with this terminology, but a lot of these applications are operating in silos. So there’s a smart contract that Cryptokitties that interacts with each other and that people send transactions to, but they don’t really need to interact with the rest of the Ethereum state in any way. So it kind of makes sense to put them on their own chain if they wanted that. But this could work with any DApp. And in the meantime, a lot of these projects are in an alpha beta stage, where the contract creator has some kind of an admin power in the contract anyways for upgradeability. So there is this implicit trust built in at this stage. So it makes sense, while we’re working on these more long-term scaling solutions, to also leverage this proof of authority sidechain method.
Griff: If you look at the DApps out there right now, they are all based on trust. Everyone has their own little currency that they are trusting that the DApp developers are going to use for this special use case they claim they’re going to use it for. And many tokens have even just decided to be obsolete, and they update the token contract because of some bug or something like that. And that’s okay. And the long-term goal is decentralization and to move towards that safely it's probably safer to start off with centralized security features that require trust. That’s what we learned with the DAO, or at least what I learned with the DAO, is that hey maybe the tech’s not ready to go full-on decentral yet. So escape hatches and all of these security features are centralizing. But even beyond that, if you look at the ecosystem now, everybody’s kind of in their silos. So I feel like a POA network to start and start testing UIs, start testing UX, get user feedback, and building this solution in V1, V2, V3. And then when sharding comes in and a scaleable network appears, we can actually start moving back towards that situation, which everyone wants, but hey—we are where we are.
Sina: For sure. You always get surprised when you put something in the real world and get people can interact with it. From an end user’s point of view, what’s happening under the hood is abstracted away from you. So if you’re getting used to interacting with this project and the user experience, whether it’s backed by a Proof of Authority chain or some shard of the Ethereum mainnet, those details can change under the hood over time without really impacting how the users interact with the system.
Griff: The user’s hitting the UI. What’s happening behind the scenes, do they even care? I don’t think they care so much honestly. We care, we want it to be kickass, built off of solid principles. And in the end that quality will shine through, at least I believe it will push through. But the user just wants it simple, fast, and cheap. That’s why we’re having these conversations, because it’s not simple, faster, or cheap right now on the Ethereum network.
Griff: How can people who want to help join the team, or at least start contributing?
Sina: On the engineering front, we have these big scopes of work that we’re starting to tackle. If anyone has any interest on working on those, please reach out. I think this S script verification for the Ethereum bridge and the return peg are at a point where the project has taken enough shape where open source contributors can just take a look at the GitHub repo and start contributing, so if you want to work in an off-chain client interacting with an Ethereum smart contract system, or if you want to work on some Solidity code, it could be a good way to get your feet wet.
Beyond that, the other piece that we’re really experimenting with is the incentives. So there’s the forks there, the jackpot mechanism, and what we’re kind of calling TrueBit classic, the one in the whitepaper. Then there’s this multi-solver approach—everyone comes in at the same time, and you play the pairwise verification games. And we’re also exploring a third mechanism now. In the original TrueBit, the solver is selected at random, or it’s whoever submits their solution first to this task. By proxy that means that the miners are picking who gets to solve the task, because they choose the order of the transactions. And one argument is that that actually doesn’t impact the security of the protocol at all because it still relies on one honest challenger. And if that original solver lies, then they’ll lose their deposit. So from the point of view of security, it actually doesn’t make a difference. But we’re also exploring a solution where there’s kind of a stake-based leader election mechanism for choosing who that solver is. And that has some nice properties. So the token mechanics side is also really interesting. If anyone is into that kind of thing, please reach out.
Griff: That sounds fun, right?
Sina: Super fun.
Griff: Just playing with game theory and, “Hey, how can we scam these guys?” Who doesn’t love that? So how do they get in touch with you?
Sina: We have a Slack, you can also just get in touch with us on <Twitter, we’re pretty responsive, or send me an email at sina at TrueBit dot io.
Griff: I do that all the time. And you are pretty responsive.
Sina: Not in the last few days, but I’m going to get better.
Griff: Well hey! You just kicked out the Doge-Ethereum bridge! And they’re still judging it, right?
Sina: The idea is that it’s going to be open to the community to play around with and see if they find any big problems with the current design. But this portion of it, we kind of broke it down into milestones. And this portion of it is kind of the quarter-point mark for the project where the relay exists on its own, the S script verification TrueBit protocol exists on its own. The next quarter of the work is to integrate these two systems together and get the one-way peg from Dogecoin to Ethereum fully working. And then the second half of the project is getting the coins back, which we’re exploring these different ideas around making the multi-stakeholders or the Dogecoin recipient deposit some stake into the relay contract.
Griff: Well that’s pretty cool. I’m curious to hear if there’s other people I should talk to — you mentioned Oscar, right?
Sina: I can definitely connect you with those guys. I think you’re already talking with Alex from Grid+.
Griff: Talking to him in 36 hours. Also these SimpleToken guys. They have a solution that looks good. FunFair, I’m talking with a bunch of people.
What about your pain points—you guys are talking to a lot of people. Can you tell me more about that project? I think it’s pretty interesting.
Sina: Totally. So we started building this stuff at TrueBit 3-4 months ago. We’re reaching out to different teams to ask them, how have you built your off-chain client, how do you test your contracts, how do you check your security of your code. And we realized that people are solving the same problems internally and they have full deployment suites and API clients that they’ve custom-built themselves. There’s just a lot of learnings that are kind of siloed away. And at the same time there’s a lot of small problems here and there. For instance, one that keeps coming up is how do you debug a Solidity smart contract? There’s really no good way of doing it other than commenting out a piece of code, re-compiling your contracts, deploying them to a test RPC or something, and running the code again.
So talking to these teams, we realized that there’s a lot of things people are building in-house which could be better as open-sourced tools, so they could get everyone working on them—you don’t have to maintain them personally. And also there’s a lot of shared pain points. So we’ve talked to around 50 developers from around this space now about their experiences developing on Ethereum, really finding the patterns there. And, on the other hand, we’ve also talked to a few of the bounties platforms. People have funds to deploy to improve the network. They want to do that. So it’s really about finding the actually implementable things that you can point these bounties towards. So that’s coming together. Robbie is going to talk about that at ETH Denver and ETHCC again. So I think there’s some interesting ones. This debugger is a really interesting one because it keeps coming up. Another one that I know you’re really passionate about is an open source block explorer. Because all these POA networks are kind of unusable until you have a real UI to see what’s going on, you’re kind of running blind before that. That’s another one that keeps coming up. There’s a lot of tidbits in there. We’re going to publish a report, this is a collaborative project with TrueBit, Web3, Status, a bunch of other people. We’re going to publish a report about the learnings. Also, after checking in with all the people we talked to, potentially open sourcing some of the transcripts from the interviews, just so people can actually see how this process works, and then fund bounties around them. So it’s going to be pretty cool.
Griff: I’m excited for Giveth to integrate into it once we can get our relay chain going. This was a great interview, thanks so much for all the downloads of TrueBit. It was really educational for me and hopefully for people who watch this. If people want to get in touch with you, it’s sina at TrueBit dot io, or sinahab on Twitter.
Sina: Thanks, take care.
See all the ScalingNOW! interviews.
Learn more about Giveth and the Giveth Future of Giving DApp.