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.
Grid+’s scaling approach is to build a trustless Merkle relay that can be used to connect DApp-specific sidechains to the Ethereum mainnet. Their solution is heavily influenced by Vitalik’s Sharding v1 proposal. They basically create a POS decentralized bridge.
The participants in the relay deposit ether/tokens into a relay contract as proof of stake sharding would require, but unlike official shards, the sidechains being relayed to operate independent of the mainnet.
The following is a brief summary of Grid+’s excellent article on their solution; it is highly recommended to read the blog post for full details!
In their system they have a large number of agents (nodes in the relay system) that can act as validators. The process begins with a set of validators that are chosen for a given epoch, and a proposer, who (like in sharding) is selected deterministically based on previous mainnet block data (with probability of being selected proportional to stake deposited to the relay contract, also similar to sharding).
To lock transactions from the sidechain to in the Mainchain, this proposer may, at certain block numbers, take a header root from the sidechain and pass it around to the set of validators for them to sign. Once enough validators sign off on the proposed header root, the proposer may call a function on the mainnet relay contract to write the new header root and claim a reward out of the bounty pool.
Because the relay network is independent of the sidechain, all incentives must originate from the relay itself. The easiest way to do this is with a bounty pool that is paid into by users of the system on a yearly basis or else subsidized by an organization bootstrapping the relay.
When a header root (with metadata) is submitted by a proposer, the validators pull block headers on the sidechain and compute the Merkle root. If the two are identical, they make a signature on the root and metadata.
Validators who only verify a given header root do not reap monetary benefit in the given epoch, but once the header is successfully proposed, a new proposer is chosen from the pool of stakers. Effectively they validate for free with the hope that they will be selected to propose the next block header.
The reward for any given epoch (block header root) is dynamic and grows with time based on parameters set by the relay network. This ensures there is some equilibrium at which the reward meets the gas cost of header submission onto the mainnet. An important consequence is that the epoch time is dynamic (assuming the reward schedule is parameterized to be dynamic). Another consequence is that the bounty pool can run dry, so depending on the associations of stakers, the pool may need to be subsidized and can go bankrupt.
Griff: Thank you so much coming, Alex. I’m Griff Green. I’m researching scaling for Giveth.
Alex: I’m Alex Miller, I work for a company called Grid+. I’m the co-founder. I do all the Ethereum stuff. I’ve been developing there for a couple years now. Thanks for doing these, thanks for having me.
Griff: This is a pretty badly needed thing in the space right now, everyone’s running into it. This is the fourth interview, so if you want to see some other ones, there are lots of people so far. They’ve been doing bridges and bridge chains. But there’s lots of interviews with Parity, POA Network, and Truebit before this.
Griff: Obviously you’re doing a lot with Grid+, Grid+ is a really cool project. And I think we’ll get into that a little bit, but the main purpose of this interview is to take a deep dive into your relay solution. This audience is really technical-minded devs who work in the Ethereum space. They have a DApp right now and they’re already considering using a sidechain as part of their strategy, and they want to launch ASAP, at least in the next 3–6 months. And they might not understand everything that you’re talking about, especially because your solution is super technical so we might need to go into the infrastructure a little bit, but these guys aren’t rookies, they’ll know what you’re talking about.
Your blog posts, your GitHub — you have some of the best documentation out there. So that should make it easier for everyone to reference. But I was even reading it to my girlfriend to explain Merkle trees and she got it! So well done, first off.
Alex: Thanks. We put an emphasis on documentation at Grid+.
Griff: You can tell. It’s really, really good. But I’m going to assume that most people haven’t read that. Can you explain your relay solution, especially focusing on the different actors in the system? I read it and I love how you compared it to sharding, so please bring that in.
Alex: So before, just some background. Grid+ is building a piece of software that would allow you to buy and sell electricity on a battery. And we were going to do that with just payment channels over the mainnet, and that seemed like a viable solution until cryptokitties took over the network. And we realized that Ethereum is probably not going to be cheap ever again. Sharding will alleviate the cost probably a considerable amount, but it’s a victim of its own success, as it gets more applications from users, Ethereum just goes up in cost. So we’ve been kicking this idea around for a while, DApp-specific sidechains, and some way to bridge them. I hadn’t gotten into the technicals, but that was the high-level idea we had. So I started running with it and the initial thought was to do a trust relay. So there will be an intermediary who would kind of control two sides of this relay between these two chains. And they would just forward transactions. I realized that there was a way of doing it without requiring a centralized vector. And I realized that the assumptions I had made about the safety were false, as pointed out to me on Reddit. So I kind of trashed that design and went back to the drawing board.
Griff: What was wrong with the safety?
Alex: This was pointed out by Jeff Coleman who is working on generalized state channels. What I was assuming was you could deposit into one side of the bridge. And because you signed some message the centralized relayer would not be able to steal your money because they would have to replay that message and it would have to go to you. But he pointed out that the relayer could just set up a bunch of fake accounts and not actually deposit money and spoof these signatures. It’s good to have flaws pointed out early and it lead to a much better design, in my opinion.
What we’re doing now is called a trustless bridge. We’ve been going back and forth between relay and bridge, we don’t know what to call them. I like bridge so we’re going to go with bridge.
So you have two smart contracts, one on each chain, and you have a set of stakers. When I say set of stakers, that’s pertaining to one of those contracts. And it’s a symmetrical system, so you have the same thing on one side as the other, with different amounts of value depending on probably which chain it’s on.
So there’s this set of people who have staked a given token or ether, whatever, into the bridge contract. And exactly the way that sharding does it, there’s a proposer that is selected randomly based on block hash. So you take the total sum of the stake and use that as the modulator for the unsigned integer of the block hash. So it’s some huge number, unbelievably big, and you mod that with the sum of stake, and you get some slice on the continuum of stakes that people have set down, and that selects the validator, with probability proportional to the size of their stake. So once you have your proposer, that actor is able to play data onto the bridge. And once that data’s been signed by a validator threshold, so that’s of the other stakers — some number of stakers have to sign off on the data — it passes through, it gets written to the state and the bridge continues.
So that piece of data in kind of a naive system would just be the last block header. But we realized pretty quickly that that’s not feasible from a gas standpoint. So if you have a sidechain that runs every five seconds, first of all it’s not possible to bridge that to the mainnet. Second of all, even if you could, you’re looking at three transactions every fifteen seconds, which is not going to work. So what we have is a system where the proposer is playing a merkle root of a set of block hashes. So if you have a sidechain that’s running like a thousand blocks a lapse, the composer packages those up into a merkle root, puts that on the relay contract, the bridge contract, and anyone who had deposited on that other chain within that block range can then prove that they did that in another set of steps. They have the ability to do that once the proposer is settled that range of blocks.
So the cool thing about that is you get a much longer settlement time, but it’s also a lot cheaper. The settlement time is actually dynamic, so you can parameterize the bridge to issue a reward and that reward is a function of the number of blocks involved, and there’s a cut-off. So if the proposer waits too long, then other people can take over. And as long as they have the right number of signatures, they can actually earn that reward. So that’s it in a nutshell, it’s pretty technical.
Griff: When you say that it’s dynamic, does that mean dynamic per DApp, or is the code dynamic once you set the parameters then it’s that way forever?
Alex: If you are bridging a chain and 128 blocks go by, and the proposer says, “Okay that’s good enough for me.” He sees the reward. There’s a reward pool and you get a reward for proposing. And that reward is a function of the number of blocks that go by and it grows as more blocks go by. So if one proposer is okay with 128, he checkpoints that. Another proposer is chosen, but that one’s a little pickier, they actually wants to wait 512 blocks because they want a bigger reward and they’re willing to wait. That’s fine too. It doesn’t matter, it’s dynamic. You just say what the end block is and it’s assumed that the start block is one after the previous end block, and that’s fine.
Griff: What stops someone from saying, “I’m going to wait two million blocks?”
Alex: There’s a cut-off that’s a parameter in the system. So maybe it’s 1,000. So if the proposer waits after 1,000, anyone can step in who has a stake with the right number of signatures and get the reward themselves.
Griff: So let’s say that I want to bridge to Rinkeby. Would that be one bridge for my DApp and if someone else wanted to bridge to Rinkeby they would use another bridge?
Alex: No. Think of it as a one-to-many bridge. So you have a contract on the mainnet and that will bridge any number of blockchains. And those are the chains themselves. So you just take in header data from these other chains and you can bridge them going that way. But since it’s a symmetrical system, you would need the same thing on Rinkeby. So there’s two bridges, it’s a many-to-many system. At a basic level, you’d have one on Rinkeby, one on mainnet, and all the Rinkeby data would go to the mainnet, and all the mainnet data would go to Rinkeby.
Griff: Is there an option for 51% attack on this?
Alex: Yeah in the same way that there is for proof of stake. I’m not a social consensus engineer, nor do I wish to be, we will be using basically whatever the EF puts out for Proof of Stake. This is pretty deeply inspired by sharding. Sharding also does the staking system. They also relay data kind of between the shards. But a lot of that setup is basically just forked in this model. Certainly the consensus is.
Griff: It sounds just like sharding, it sounds like you’re using the validator manager contract.
Alex: That’s very similar to what it is.
Griff: What are the specific differences?
Alex: I need to go back and read the sharding doc, I’m not an expert in it. But obviously the biggest difference is you can bridge any number of chains that are third party. So it doesn’t need to be subsumed into the mainnet. With sharding you’re still going to grow the state, so there’s a global state I believe. Is there?
Griff: I think there’s a global state and the same account spaces in different shards, so in that way it’s similar.
Alex: Yeah there’s different account spaces, I’m just wondering if on the mainnet with sharding if an archiver will have to maintain the entire state. I’m not sure if they would, I assume they would, but I don’t know.
Griff: I would think that there are definitely applications that would want to. Like Etherscan.
Alex: But basically it’s just like a third-party sharding for any type of chain — proof of stake, proof of work, proof of authority, application-specific, gambling chain, whatever. All of those scaling solutions at this point are very exciting, but they’re all kind of driven by the Foundation in some way. And I like this wave of like bridges because it seems like a community effort, which is super cool, and it also allows you to iterate faster, because you’re using these battle-hardened tools that are probably the hardest part. So like the blockchains themselves, the consensus engineering that went into blockchains, and you’re using those as building blocks for bigger networks.
Griff: I think it’s pretty cool, too. Many hands make light work. So if we have Swarm City and Parity working on a solution, POA Network is running with Parity’s solution. I’m excited to see other people take your solution and Truebit’s solution and the other bridge solutions and have these little groups that compete to make the best thing. And what do you know, someone will win and they’ll have 90% of the bridge contracts.
Alex: It will be fun. I have no ego about it. If this is not the best solution that’s fine. I think in this space we get a little carried away with visions of the future and make the assumption that this one thing that’s marketed really well is going to capture all of the market share for this problem that it hasn’t begun to solve because it doesn’t exist yet. I will enjoy seeing several of these on the market soon.
Griff: So what’s the incentive structure, what makes the proposers — obviously they get a bounty when they propose their blocks. Where does this bounty come from? Why do the actors act in your system?
Alex: Yeah so there are a couple ways. The first is if someone wants to bootstrap a bridge, they can pay into this bounty pool. So there’s a pool where all of the bounties come from from proposals or awards.
Griff: On each chain.
Alex: Yeah. So the question is, who pays into that? The first is someone who wants to boostrap it. The second is if someone wants a one-use pass. So you can allow these bridges to whitelist participants if they want to pay for it, they pay a fee that will cover gas costs and probably a little bit more because it’s a one-time fee. And they do that and they can make a deposit. The withdrawal is free. The user pays the withdrawal.
The other way I think is cooler is a subscription. We don’t have any crypto systems with subscriptions. You can imagine paying a couple bucks a year, the average cost for a relayer is not going to be that high because it’s a settlement layer so you’re not going to use it all that often, so I can imagine a yearly subscription fee to be on the whitelist. That’s really interesting, we’ll see where those models come from. I think for a while they’ll just be subsidized, and that’s fine. But I’m pretty excited to see if they can be profit systems, because they’re really just collections of people or machines, collections of actors who want to earn some revenue for their bandwidth and their stake.
Griff: Does it matter if you’re using Geth or Parity or any of that?
Alex: It shouldn’t. The tests were done with Parity. They actually treat signatures a little differently, but the contracts handle those. So there’s the IP155 that changed the b value in vc signatures. But in the client itself the only thing that matters is basically just using RPCM.
Griff: If on testnet the token deposit can’t be testnet ether. Could you modify the contract to use a token instead of the mainnet native currency?
Alex: So actually right now they’re only designed for tokens. I could add ether, I just haven’t gotten around to it. So it’s ERC20 to ERC20.
So let me talk about how the assets are transferred. The only thing that distinguishes a bridge from an atomic swap, this is something a lot of people get confused because they haven’t really thought to fine enough detail, but there is a subtle difference between these things. So with an atomic swap, you have a counterparty. So you are locking up tokens in one chain and you are releasing them in another chain. So you put something in a box, you give them the key, and they put something in a box and they give you the key, and you can both unlock the respective boxes. So that’s an atomic swap. And people have been talking about doing those with Bitcoin and Litecoin, but that’s trading. So you have to have a counterparty. So you what you want is to move tokens into another chain that belong to you and will always belong to you. So what I’ve found is you have to replicate them somehow.
So the way that it works with the bridges we’re building is right now we have an admin. I’m not sure you have to have an admin, I think anyone can do this. The call function on the bridge contract creates a token that then maps to the token on the other bridge. If for instance on the mainnet you have a token that starts with AB, you call this function on the sidechain with the AB parameter, it creates a token, it moves all those tokens to the bridge and it maps them to AB. And the number of tokens and the name of the token symbol are all identical. So basically you are replaying the transaction that was used to create the initial token. So it’s really important to have these things mapped 1:1, because if your accounting goes off, you have big problems. But it shouldn’t as long as all those tokens are removed to the bridge contract initially.
Griff: So it’s really just a teleportation device. You send it in and then it comes up here, you have it on both sides, boom. And only ERC20 tokens, that’s really interesting. I take it that that’s because you’re only designing this for Grid+, right? Can you explain how you expect to use it?
Alex: As I mentioned, we realized that we aren’t going to pay $20 to open and close a stage account every month, so we’ll be using a sidechain. I don’t know if it will be our own or if we’ll use a common one, but regardless we’ll be using a sidechain and we need bridges, so we’re building them.
One of the reasons we’re building them, one of the reason we like this idea so much, is we have these devices called agents. And we want these to be the rails of the crypto ecosystem. At a basic level, you can think of a Ledger. A Ledger has a secure sign-in chip that’s different than the chip that runs the program that you see when you plug it in to your computer. The reason it’s secure is your signature never leaves your secure sign-in chip. So we extend that idea to a much bigger general computer, and put it on IOT. So what this allows us to do is run applications on a hardware wallet. You have access to funds but they’re secure in the same way your Ledger is secure. Your keys are never going to leave your chip, you can set up permissions to require physical PIN entry if a transaction amount exceeds some threshold. And other than that you can do remote signing. So if it’s for a tiny amount of money or if you just need a signature that isn’t on a transaction to move ether, it can do that if the general compute unit says that it’s ok.
So what this lets us do is create applications that run on this IOT device. And we really want to build the app store of crypto. So what we want in this app store is apps that will earn users money. So give users a reason to buy these things and show that they can earn some value by having it on and staking their money with it. So we’re going to be seeing a lot of staking apps, this will probably be the first one. So we will have official Grid+ bridges and those will run on agents. The bridge software is open source, MIT license, so anyone can create their own bridge networks, but we’re going to have specific agent ones. And those will be to run the relay for whatever chain we’re using. And we may do others but certainly that one. Those will stay Grid, which is our token. Those will require an agent, so there will be a whitelisted group of agents. But we’re also coding this software open source and I hope there are other bridges as well. We don’t want the agents to rule the world entirely.
Griff: There’s a lot of cool projects that are doing these decentralized deployments of hardware. Obviously I worked for Slock.it, we were trying to do it with the Ethereum computer, Swarm City has something very similar, and Jordie’s doing a decentralized personalized server idea where you can run PFS, Monero node, Ethereum node.
Alex: That’s like, what’s that project that’s been going on forever? Urbit? That was the whole idea. It’s like ten years old and they’re still working on it, which is amazing. They created this whole language, the idea was that there was a different container computer for every person, there was a private key, you could do different cryptographic operations, you could store it in the cloud safely because you knew the key to unlock it.
Griff: Wow, that’s really interesting. I’ll have to look into it. I don’t know that Jordie has seen that, so we’ll have to dive in. We’re doing this for Catalonia, but that’s off-topic.
So are there any points of centralization? I know there’s this admin guy which you’re hoping to move out. Are there any other points of centralization in this system?
Alex: So the admin guy could absolutely be replaced with consensus. The point of decentralization is social consensus. When I first started this, I looked at relaying proof of work block headers. It was kind of infeasible. With Bitcoin, you can tell the block header difficulty right away. It’s the number of leading zeros. But with Ethereum, it’s different. You have to basically run it through this huge three gigabyte DAG, which you can’t do. So that was kind of a non-start. And I realized, that’s okay, I can do it with Casper. We’re going to Casper. But then I thought about it, and I thought BTC Relay, which was kind of the predecessor for all these things, had this cool difficulty tracker, so you could tell how much work had been put into this probabilistically. Casper doesn’t have anything like that. So basically to extend social consensus you need to replicate it. So to whatever extent that’s centralized, that would be the centralization point of the system. But it will be interesting to see how that pans out. My opinion is that we can’t go anywhere without proof of stake. We can’t depend on proof of work to run these systems at scale.
Griff: Couldn’t agree more. On the points of centralization, it sounds like it will start out as like some DApp that will kick-start their bridge on whatever chain they’re going for, and they’ll have all the stake and they’ll be the main one and then slowly people will come in.
Alex: Yeah, so for the bridge that we would run with the Grid, it would be the biggest Grid-holder would potentially be the biggest points of centralization. And that would be true for any token.
Griff: That’s an interesting point too. Because there’s Grid holders and there’s Grid holders that would actually send it into the relay. You’re not automatically going to put Grid into the relay contract, right? It’s always going to be someone decides?
Griff: So what’s the current status of the project?
Alex: It’s in development. The trustless version is not that old. It’s maybe a month old. I finished the contract pretty quickly. That’s not true, it took a while. I’m working on the client now. It’s good, running with it. Going as hard as I can. I want to get this done in the next couple months, but we’ll see.
Griff: You’re a one-man show over there.
Alex: I’m the Ethereum team at Grid+. We have to do this energy stuff. In fact the core of our business. You’re going to be able to buy and sell electricity with your agent, which is great, but we can only operate in Texas to start. That whole time frame is long. If that was the only thing we were doing, the only people who could use these agents are people in Texas. I like Texas, I live in Austin. But I think there’s a world full of crypto fans who would love to stake bridges with their agents. We want to build up this app store that will appeal to people all over the world who like crypto who want to earn money so that we can get the agents other places. So that’s kind of my mission, to build cool stuff for the agents.
Griff: Eth devs have the best job. It’s pretty fun. So it sounds like you have the smart contracts pretty much done, but they need to be audited.
Alex: Yeah, they’re version 1. I wouldn’t trust them with large amounts of money. I do think we could set up a bridge pretty quickly and maybe limit the amount of stake and tell people don’t stake a bunch please. But I would not put this into heavy production system until it’s been audited. It’s a big contract so it could take a while. My plan is to run it as quickly as possible. Expect a beta test soon.
Griff: You’re working on the client?
Alex: The scope of the client is bigger than the contract. I started that last week. The scope isn’t tremendous, it won’t take that long. It’s hard to estimate how long it will take. My projection is 2–3 months.
Griff: Not bad. Are you going to target Rinkeby?
Alex: We could. I don’t really care, whatever there’s demand for. If you want Rinkeby we could do that.
Griff: What could people do to help?
Alex: They could apply for a job at Gridplus.io and come build bridges with me. If they want to look at the contracts, if they want to audit them then that would be very helpful. Or just look them through. More eyes is always better, just check them out. And if they want to make improvements, they could do pull requests. There will be some bounties on ETHcoin that will be coming out around ETH Denver that will be contract-specific.
Griff: That sounds pretty cool. Do you have a place where people can find you? What’s the best way for people to ask you questions about this stuff?
Griff: So you have an idea for a front-end facing DApp, right?
Alex: Yeah. There needs to be some interface. My idea is just a React DApp that I haven’t started yet. Basically you are on some network and you want to move to some other network. And you have some tokens and you press a button and sign a transaction. And that basically deposits it. And then you go to that other network and say which network you’re coming from, or it can store that in your browser. And there’s a withdraw button and that’s basically it. But behind the scenes it interacts and stuff. And ideally I would like that to be sort of an SDK and the apps could integrate that into their own websites, they wouldn’t have to leave and go to gridplus.io, because I know applications like keeping users on their websites. Which is fine. So that stuff would be coming after the client’s done. Keep an eye out, keep an eye on the Grid+ github. And I’ll tweet about this stuff.
Griff: Very cool. There’s a lot of great front-facing DApps that have done something similar to this. Not with two chains, but MakerDAO migrated from old coins to new coins, same with Swarm City. They started out with Arcade City tokens and moved them to Swarn City tokens. I think you’ll be able to find someone to help you out with that.
I have a bunch of awesome questions. Cloyne Hodel says, “How many transactions per second can these different relay and sidechains, proof of authority, etc, actually pull off? I know Igor’s POA network gets 60 transactions/second. Is this the same with what you guys are looking at?”
Alex: That would be sidechain-specific. I don’t know. POA can probably do 50ish, that sounds about right. For relaying the number of transactions, it’s like whatever the sidechain is. So again, you relay one piece of data, which is a hash. And that can represent the last 1,000 blocks of the sidechain or 10,000 blocks, it doesn’t matter. So as fast as the sidechain wants to run, you want to run your sidechain at one block per second, that’s fine. You can relay a merkle root with 100,000 headers and pack that down into one. So your user’s withdrawal will be a little more expensive, but the cool thing about merkle proofs is their cost only grows on the log scale. So the difference between 1,000 and 10,000 gas-wise is not that big of a deal.
Griff: Which is really cool. And your blog post explains that so well. Again, your documentation is so good. So I really hope people take advantage of it. The pretty pictures, and pretty charts that say this much for this many transactions. So nice.
Alex: I like measuring gas costs, that’s something I enjoy doing.
Griff: That’s kind of the name of the game, that’s why we’re all here.
Huxtable Sweaters says: Will agents be able to simultaneously stake for Casper, Grid+, and other DApp sidechains using your relay network code contracts?
Alex: So I think the question is, they know they can stake for bridges, can they also stake for Casper? I don’t know. So the problem with Casper is that it looks like we’re probably going to need a full node. I don’t know if we can pack a full node on an agent. Believe me, we’ll look into it once Casper’s released, we’d love to get it on there. But the short answer is I don’t know.
Griff: Maybe you have two scales — the Grid+ agent and the Grid+ agent Casper super.
Alex: That’s a possibility, but you’d have to convince my hardware guy.
Griff: How many transactions does it take to do the process? You start with depositing and withdrawing.
Alex: It’s terrible. It takes 1 to deposit. Right now it takes 3 to withdraw, which is terrible. The total gas I believe is under half a million, so it’s not super expensive. So this is something we need help with. I just didn’t slice up the bytes efficiently enough. I packed too many variables into these function names, so the stacker workload, I had to split it into 3. So the idea is to convert it and get it down to at least 2, I could definitely do 2, hopefully 1.
Griff: Huxable Sweaters says, “Are you looking at Casper or taking your own approach?”
Alex: It would be off this sharding one. I believe sharding also uses Casper. We’re not going to design our own consensus system.
Griff: Also from Huxable Sweaters: “What examples are you looking to for a fee structure that would incentivize staking but not impose a noticeable burden on retail electricity users?”
Alex: For the electricity stuff, they’ll probably start off on sidechains. They probably won’t start off on mainnet. And if someone wants to move their tokens on there, they can do that. If we have the bridge on the agents and our customers want to move ether to the sidechains so they can buy electricity from us, we’ll pay for them to use the bridge. Because it will be pretty small.
Griff: Mark Booth asks the taboo question you should never ask a dev, but I’ll ask it anyway. “Target date for beta testers in Texas to get a smart agent and begin using Grid?”
Alex: This is outside of my purview because I’m not actually working on this. I think end of the year is our target. We have the retailer, we’re working on the agent, so one of our offices looks like a machine shop, which is pretty cool. And we are integrating with an upstream provider. We’re working on it. The slowest part of it is going to be regulatory stuff.
Griff: You never know what could go wrong. There’s so many little pieces and you expect, “Oh yeah! We’ll get that done in a week.” And it takes a year sometimes.
Alex: We would love to have it done as soon as possible, but realistically probably the end of the year. And it will probably be a hundred people in Texas. I don’t know if we have a signup yet, but we will soon. But signup. Particularly if you’re in Houston or Dallas.
Griff: Very cool. And will you just send them agents?
Alex: Maybe. You might have to buy them, I don’t know. I’m not going to make promises you won’t have to buy them, but we’ll try to incentivize them.
Griff: This is such a cool thing. Thanks so much for taking the time to talk and take a deep dive. I hope someone watches this and dives in and ends up being really productive with you. I like what you’re working on. We need more decentralized bridges.
Alex: I know Parity’s working on the trustless version, but it will be interesting to see what is the most efficient system. I don’t know, actually. The one before where you had to play each message, it was super inefficient. But the way they’re doing it may be a little more efficient. So it will be interesting to see both of those on the marketplace and see if there’s a demand for the more decentralized one. I’m sure there will be a demand for being a proposer.
Griff: Everyone loves running a machine and making money.
Alex: I have a raspberry pi by my desk. If it could just be running and making me money, that would be great. We should have a “cha-ching” play on the agent, have a cash sign display on the touchpad whenever you get chosen as a proposer.
Griff: There’s so much fun we can have with this stuff. One more time — what’s the best way to contact you?
Griff: Also we have ScalingNOW! general chat on Riot, so if you want to dive into that, or if anyone watching wants to see people chat about scaling solutions. I saw that Swarm City is basically developing a solution with Parity. So thanks so much, see you soon.
Alex: See you later.
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