Best General RenVM Questions | September 2019 *These questions are sourced directly from Telegram
Q: Given the RenVM Mainnet Roll-out Plan, what are the differences between how Darknodes participate in the P2P Network, Consensus, and Execution within RenVM?
A: An outline of each component and its role in RenVM system is outlined below:P2P NetworkThe peer-to-peer network is used for two core purposes: peer discovery, and message saturation. Peer discovery allows Darknodes to learn about other active Darknodes in their shard, and in the network at large. Message saturation ensures that all messages sent around the network are seen by everyone.
ConsensusThe consensus engine is used to reach a strict ordering of transactions that go through RenVM. This ensures that the Darknodes powering RenVM are able to agree on what actions to take, and when.
ExecutionThe execution engine is used to run secure multiparty computations. This is how actions in RenVM are ultimately taken. These actions involve generating private keys, signing interoperability transactions, and, in the future, running general-purpose application logic. And all of this in secret.
Q: How do I shut down my current Darknode(s)?
A: Follow this instruction set explicitly and you won't have any issues: https://renproject.zendesk.com/hc/en-us/articles/360020365234-How-to-Fully-Deregister-a-Darknode
Q: Is running a Darknode on Chaosnet useful for the team?
A: Yes, by running a Chaosnet Darknode you are inherently helping us test. One of the core purposes of Chaosnet is to the real world incentives of RenVM. Running (and continuing to run) a Chaosnet Darknode says something about the incentives at play: they’re enough to get people running Darknodes. And this helps us! In fact, by not running a Chaosnet Darknode you’re also inherently helping us test. It’s telling us there’s something not quite right with the incentives.
Q: And what's the incentive for someone to collude and attack the network during Chaosnet?
A: The ability to steal real BTC/ZEC/BCH, the want to help us test the network, the want to betray their fellow colluders and take their REN bonds, and of course, some (wo)men just want to watch the world burn.
Q: All of this de-registering and re-registering for mainnet is a bit annoying, is it necessary?
A: We do certainly understand the point as it's been discussed at length but registration for the RenVM Mainnet is a necessary component (applying automatic updates for current Darknodes to run RenVM is not technically feasible). This announcement is very much an administrative piece to ensure our community has plenty of time and notice to proceed at the speed they prefer. Chasonet is designed for testing and those willing to actively experiment, but certainly not mandatory and there is no pressure on the general community to be active during this period.
In summary for those who prefer to be less active, should de-register their current Darknode(s) and wait patiently for activation at the release of Mainnet SubZero, no other action is needed.
Q: Is RenVM secure against quantum computing?
A: The core of RZL sMPC is theoretical secure. This means that no amount of compute power can break it (making it post-Q safe). There are some parts of it that are not (zkSNARKs and some hashes that aren’t known whether or not they’re post-Q safe) but these are easy to replace (with zkSTARKs and some post-Q safe hashes).
RZL sMPC provides ECDSA signatures because that’s what it is used by Ethereum, Bitcoin, etc. Whatever solution they come up with, will be the solution that RZL has to be upgraded to use (the whole point of RenVM is not to tell other chains how to do things, and still provide interop; this means waiting on them to define their solution and then working with that).
In short, if a QC can steal funds from RenVM, it’s because it can steal funds from any Ethereum/Bitcoin/etc. private key.
Q: If I don't deregister my Darknode by RenVM Mainnet, will I lose my 100K REN?
A: The REN bond is safe forever. You can deregister your Darknode from the legacy Mainnet whenever. We recommend doing it now, because it can take three days, and once Chaosnet rolls around that’s where our support focus will be.
Q: When shifting in funds, say a user doesn't have eth funds and this call fails const newSigResult = await ethSig.submitToEthereum (web3.currentProvider). what is the best way for that user to pick up where they left off if they leave the web page to get some ETH, and then come back? Should the app generates a new shift in the object, override the params and gateway address objects, re-submit to RenVM, and then make the above call again? Assume the transaction info such as original params and gateway address are stored in local storage so those will be available when the user comes back.
A: This is the approach we take. We store the RenVM tx in local storage and then when the user comes back we can construct the Ethereum tx and hand it to them for signing again. You can construct the RenVM tx locally and store it before asking the user to send their BTC to the gateway to protect against unexpected shutdowns. This way, you can recover from them leaving the app at any point in the process without loss of funds. (This also allows you to resend the RenVM tx in the event that the first send fails for any reason.)
Q 1: Could you elaborate on the proportionality of (a) Total value of bonded REN (b) Total value of assets under RenVM control? Does RenVM require (b) <= (a) at all times? RenVM would need an Oracle to determine the USD value of both (a) and (b).
A 1: The oraclisation is done by the Darknodes. Each of them assesses what they determine that value of (a) and (b) to be and if 2/3rds of them independently decide (b) can be increased then the network will be able to go ahead with the computation. We do require (b) < (a) but have not determined the exact ratio. Because Darknodes are randomly sampled (and constantly reshuffled) from the entire group, this value can consider the entire amount of REN bonded (not just the REN bonded by one shard).
Q 2: There's potentially an incentive-misalignment issue here: Darknodes would want to bypass the (b) < (a) limit in order to continue to process more tx's and collect fees.
A 2: True, but there’s also a natural incentive for Darknodes to want to keep the network secure. A hack would likely render their REN to drop dramatically in price and they’re REN will be locked for 2-3 months after deregistration. This is also true of users. They should be wary of keeping assets locked up when it nears the secure threshold. This can be encouraged by scaling down the burning fees/raising minting fees to encourage the movement of funds “in the right direction”
Q: Quick question: right now, a developer can choose to wait for 0 confirmations before minting zBTC on Ethereum when shifting in real BTC. Will the RenVM network require a minimum number of bitcoin confirmations, or is that always up to the application developer? If it's up to the developer, what if the developer chooses 0 confirmations, mints zBTC, and then double spends on the bitcoin network, invalidating that original bitcoin transaction? shouldn't that invalidate the zBTC that was already minted from the original 0 conf transaction?
A: The developer cannot choose. RenVM will wait for the appropriate number of confirmations. On Testnet, this number is currently set to zero because it makes testing easier. On Mainnet, there will be systems for people to take on the “confirmation risk” and provide float. Devs can also set it up so that people can deposit ahead-of-time. We are also exploring Lightning and similar concepts.
Q: I've noticed an increase of tx's made through RenVm, how tests are going on; have you met any unexpected obstacles?
A: We’ve encountered a few issues with nodes when they are rebooted/crash (we are constantly rebooting/crashing them to make sure the network continues to operate as expected under those circumstances). But, we have fixes in the work for all these issues and it hasn’t prevented us from being able to add new features (BCash and SegWit support has recently hit Devnet and will be arriving on Testnet soon).
Q1: If home chain = destination chain, then RenVM is effectively a mixing service?A: It can be used that way, definitely. But, it has to have a few more privacy features enabled, shifting alone won’t do.
Q2: RenVM mints Aztec notes for example?A: Yep, that’s the plan. But we need to wait until the Ignition ceremony before this can be done. It’s one of the next features in our pipeline though! BTC would “appear” on Ethereum with no known owner. And, if you wait an amount of time between getting the authorizing from RenVM and using the signature, then it would be impossible to trace it back to the request that went to RenVM.
Q: When I go to the Command Center, the page doesn't load?A: One has to be on the Kovan Testnet (on Metamask). To do this, select the top middle button on your Metamask tab and click Kovan Test Network (Purple circle). If you’d like to see it in action, submit a trade on our Testnet Dex Demo (https://renproject.github.io/renvm-demo/) and see it proceed through RenVM via the Hyperdrive tab: https://dcc-testnet.republicprotocol.com/hyperdrive
Q: Mixicles & RenVM: It seems like Mixicles could be used to preserve privacy features for on and off-chain settlements in a blockchain agnostic way. Wouldn’t this be seen as a threat as smart contracts could now replace a darkpool while maintaining the element of anonymity?
A: Mixicles (and all other ZK on-chain stuff I’ve seen) gives you privacy on the chain. So you can prove things have been done right (one of the things we like about public blockchains), without exposing any information about the thing (an issue with public blockchains). But, the prover still has access to the information. This rules it out for many kinds of private apps. RenVM gives you absolute privacy. You can do things with data, and prove things about data, without anyone anywhere ever knowing anything about the data. This is much more general.
Q: Can’t people just fork RenVM?
A: What ultimately prevents forks is the network effect. All projects that want to take decentralization seriously need to open-source their implementations. Almost by definition, a decentralized network is nothing but its community of people willing to work together; this is the very essence of “trust no-one except for the majority”. If you refuse to open-source you don’t have a community, you have hostages.
Building up momentum and creating a large network and community is incredibly valuable and not something that can be forked. Bitcoin is still Bitcoin, despite the large number of forks that have been created, and most of the time forks don’t overtake or outpace the original because there is too much inertia in the original community.
There are other, less philosophical, benefits too. Open-source code means you can get more feedback, people can help fix bugs, identify potential security issues, anyone can validate the implementation, people can build their own implementations (resulting in highly desirable “N versioning” which prevents a single bug compromising all nodes).
https://renproject.zendesk.com/hc/en-us/articles/360001180915-General-RenVM-Questions-September-2019
No comments:
Post a Comment