Ren is awesome, but we need an updated and clarified security model

General
1

Ren is awesome, but we need an updated and clarified security model.

My two reasons for investing early in REN

  1. Using fees from transactions to incentivize a large diverse set of nodes seeking profits is a brilliant new model for decentralization. It’s like mining, but instead of solving math puzzles, we are moving Bitcoin to Ethereum!

  2. Hiding the private key with ZK proofs looks like an important innovation.

I agree that projects do not need to start fully decentralized and I also agree that it is wise and necessary to take it slow.

In April, this article


points out
In order to dis-incentivize bad actions (e.g. stealing collateral), Ren validators for each shard must collectively bond greater than or equal to 3x the value (in REN token) of the BTC secured in each shard.*

3x seems like overkill for several reasons, and Loong confirmed this on a recent forum post. Value of REN securing nodes too low
“RenVM are, even at today’s TVL and TVB (total value bonded) more expensive than 51% attacks against Bitcoin or Ethereum themselves.”

If the value of REN nodes does not need to be 3x higher in value than tokens locked on the network, then
what is the correct equation?
And how many nodes do we need to be decentralized?
https://darknodes.online/?s=03

Meanwhile, RENbtc locked on the network has been growing at a faster rate than transaction fees since launch. We need to change that direction.
Raising fees further incentives big players to lock more BTC onto the network. The continuous fee might be a solution, but I agree to not implement that just yet.

Ren should instead focus on the key to its security model,
thousands of nodes operating profitably around the world .
How can we make it easier for investors to become node operators?
How can we make it easier for nodes to measure and remain profitable?

Another problem with raising fees, is if it works!
If transaction fees double again, and that drives the price of REN to go up 5x again, the network may end up controlled by a few whales.
In order to get a diversified world wide group of node operators, we need a lot of investors to become node operators before most of the world is priced out of 100K REN. Ren’s decentralization may be impossible if it doesn’t have enough nodes and it costs $150K to buy into a node.

But that brings us back to the same questions.
How many nodes do we need?
And how much profit do they need to secure the network?
If we don’t have a security model goal, how can we even test solutions?

One final point I have learned after launching projects on the internet for 20+ years. Winners win immediately, and duds stay duds. This means, that RENbtc is a huge winner. Adoption rates like we have seen in RENbtc do not come often. Lets double triple quadruple down on bringing BTC to Ethereum. What can we do to make it easier for Bitcoiners to use the Ren Protocol?
Meanwhile, expectations regarding volume from ghost town chains and shitcoins are too high in the short run. One year from now, 95% of volume on REN will still be RENbtc. Five years from now, hopefully we can diversify, but if anyone thinks Dogecoin on Ethereum can move the needle, they will be disappointed.

4 Likes
2

It’s TVB >= TVL/3.

It seems you multiplied rather then divided the 3.

I don’t think it makes sense to make it easy to become a node operator. How would you propose doing so? I actually think the incentive economics of RenVM are one of its strongest points.

I agree this is an important thing to accomplish. RenJS integrations into partner UIs allow for the best UX for bitcoiners. Curve’s wBTC and renBTC mint functionality is one of the most key integrations IMO. We need to work together in showcasing this strength to other protocols. I’ve tried sharing this with Aave, and I know members of the team have shared this capability with Maker.

Having a BTC-onramp on heavily used DeFi protocols is key to your question. I believe an active community with members sharing this information objectively and not with a shilly-vibe can help this. At the end of the day, a RenJS integration helps both parties. Volume for RenVM and BTC liquidity for the partner.

1 Like
3

So total value bonded 42 million needs to be 1/3 of the total locked? $300M/3 = $100M.
These numbers (if I have it right this time) is much better!
Am I now correct?

Regarding running a node, the easiest hosting options says you have to know how to use “command line”. That scared me away.
I did have a developer help me run a node and I realized in addition to the technical aspects, tracking income in RENbtc which is released over time makes tracking profits tricky. Tutorial videos on how to set up a node and and some sample spreadsheets on how to track returns would go a long way.

Regarding attracting Bitcoiners we need to teach not only about RENvm, but about how they will use their RENbtc - uniswap, metamask, curve, WBTC, etc. and where to find yield.

4

I think the team went with the command line route because of this reason

Running a Darknode for RenVM is a responsibility. It requires moderate involvement in the network and community. There is an assumption that you have some technical know-how and understand how to utilize your computer’s command-line interface (CLI).

You will be required to occasionally update your Darknode and refill it with ETH, so please do understand the responsibility prior to moving forward. If you are not committed to being involved in the network’s safety, we’d encourage you not to proceed. ‌

I agree with this, it can be a little confusing to someone who never used ethereum before. I think we(community members) should be making these tutorials, and not wait on the team to do it.

5

The reason the bonds should be targeted to be worth 3x more than the assets locked, is because if you have more than 1/3rd of the nodes in a shard, you could gather up all your private key shares and attempt to take the funds held in custody by that shard (assuming there is no Greycore acting as a second signer).

It is basically the last line of defence, if the other layers of security can’t hold out against the attacker (the Greycore, frequent shuffling of shards, expected future income you would lose out on etc.).

To reach this target, there are two primary levers we can pull:

  1. Change fees to incentivize behavior (haven’t been used yet but we will be begin to do so soon)
  2. Drive more integrations to get more volume which increases rewards to the nodes and the hence the value of the bonds
6

If there is $300 million BTC locked on the ren protocol, how many nodes do we need at what total REN locked value?
The Randy’s reply comment implies we would only need $100 in REN locked, while you seem to think we need $900 million?!
There needs to be consensus on the security model that doesn’t vary within the community by 900%.

Before we start pulling levers, we should determine what the goal is!

Also, the answer is probably granular with different levels of risk. Just because a theft is mathematically possible, doesn’t mean it is likely in the real world where there are additional real life frictions.

7

To steal funds from a shard, you need to control 1/3 of the nodes in a shard (as well as Greycore while they are active). So to be profitable, the value of the Ren bonds in those 1/3 shards needs to be worth less than the value of the funds locked in the shard.

Example - There are 1000 nodes online. There are then 10 shards of 100 nodes. There is $100 million locked in RenVM total, so each shard caretakes $10 million. If 1/3 of a 100 node shard successfully colludes, they will steal $10 million. But by doing that, those 34 nodes will have their bonds slashed so they lose their 100K Ren each. The 34 nodes lose 3,400,000 Ren. Each Ren must be $10 million/3.4 million = $2.94 each to break even on the hack attempt. 100 nodes * 100,000 Ren * $2.94 = About $30,000,000 TVB for that shard, or TVL x 3. So, if TVB is less than TVL x 3, an attack will be profitable (but really who would attempt an attack unless they are really going to profit, unless it is just to harm Ren reputation?) So the TVB needs to be a quite a bit lower than TVL*3 to make an attack make sense.

1 Like
8

Thanks! I feel like I am coming closer to understanding this.
Tell me if this is right.
If there is $10 million in a shard and the REN bonded on that shard equals $10 million, then for $3 million nodes could collude to steal $10 million, but then they lose their $3 million bonded.
So if the attack cost $0, the profit would be $7 million. Is this correct?
The next question is if an attack actually cost $0?

9

I don’t know how much that actual attack would cost, if anything, but yeah 34 nodes have to come together, and they would lose their $3.4 million in Ren value through slashing but grab the $10 million for a total profit of $6.6 million. This is why the bonded value should be TVL x 3, or thereabouts. The slashing of the 1/3 nodes would cost as much as they grab in shard TVL so it wouldn’t make sense unless it was an irrational attack (trying to hurt Ren reputation).

10

So based on discussion, it sounds like approx. USD value locked in Dark Nodes is currently 1379 * 100K * .33 = 45.5M? While TVL is ~351M?

In this case it seems like an attack would be profitable depending on how many nodes are in a shard? And the main obstacle to a collusion occurring currently is Greycore intervention? It sounds like the original poster’s concern is valid when it comes time to decentralize no?

2 Likes
11

Mint fees were just raised to .2%, the first step in addressing that TVL/TVB correct ratio. Up to know I believe we were more concerned with adoption since Greycore is handling transactions. I am sure in coming months more emphasis will be put on progressing to the next phase.

1 Like
12

I hope I am wrong, but I fear increasing transaction fees simply attracts more whales and longer holding. I think the continuous fee is the solution in the long run, but I agree now isn’t the time for that.

What we really need is 5000 independent node operators earning a nice dividend without raising fees.
And we triple down on RENbtc volume growth.

Once there are 5000 node operators, we raise the transaction fee and turn on continuous fee and all node operators get rich, REN moons, and we turn on decentralization.

I love REN but the current plan seems like we are raising fees and chasing shit coins!

2 Likes
13

It is easy to say ok, let’s have 5000 node operators and tons of volume - but to attract node operators there needs to be incentive - node income - which comes from fees. And for volume growth - these things take time, and one of the obstacles to volume growth is decentralization. To get to the next phase, Mainnet Zero, we have to have the TVL/TVB ratio in check. We have to raise the bonded value (more nodes and Ren tokens worth more which requires more fees & more volume). This is the first step. More integrations are coming soon to create more volume.

1 Like
14

Over time, with more high-volume integrations, and more usage overall, adjusting the fees should take care of the concerns raised in here. It does not make sense to look at the data we have so far and draw any conclusions on how things will look in the future, because we have not manipulated the fees yet, and we are still in a very early growth phase in terms of adoption of RenVM.

2 Likes
15

There is the additional point that an attacker would need to effectively be able to find and bribe 34x unknown node operators in 24 hours and convince them to trust the attacker in order to collude. This is pretty much impossible (and setups like Ethereum 2.0 make similar assumptions about this difficulty). So, the attackers only option is to attack the network at large by registering a lot of nodes in an attempt to end up in 1/3rd of a shard. However, today, this would require ~$15-20M which is a significant initial capital investment for an attacker. Most attacks we see today that come anywhere near this range are done through flash loans (which you cannot use in this context), implying that attackers do not generally have $15M lying around to risk on an attack.

1 Like
16

In other words, to get 30% of one shard, an attacker would need to get 30% of the entire network. (The other option of finding and bribing on the actors on each shard seems rather unrealistic for the foreseeable future.)
This means that at today’s value it would cost probably $20 million to attack one shard. So then it depends how many shards there are, so this looks pretty safe!
(I don’t think the network is sharded yet, but my concern was that there is a clear path to decentralization backed by some math that makes sense. I now see the path!)

17

I am skeptical that adjusting fees will allow to control TVL/TVL ratio, and if finally works, most probably will severely limit the volume. I do not have even a proposal, but I think other options shall be evaluated as well.

1 Like
18

This was an interesting post from @Loongy today in the main telegram group.

“One other point worth adding: over-collateralisation is less important (and thus not a strict/hard target for the network) in RenVM because shards will be shuffling every day, making it very difficult for an adversary to bribe operators. In Keep, the nodes custodying funds are around for months, so bribery is trivial, and over-collateralisation is needed to defend against it.”

1 Like
19

Yes, especially when the project has the greycore as second signers… so an adversary needs to control 1/3 of a 100 node shard that will only exist for 24 hours, as well as convince 1/3 of a greycore - that the operators projects’ depend on Ren for their success - to basically commit project suicide for the spoils of that one shard.

This is my argument for not considering worrying about our TVL/TVB ratio right now when debating fee increases or decreases.

20

I think have renBTC on Aave would increase renBTC usage significantly. On the Aave forum to add renBTC (posted by DeFiFrog) there are instructions on how to fill out the form to formally request adding renBTC to AAVE. Is anyone from the team or extended team working on that, filling out the form I mean?