Feedback Request for 'R' Protocol Proposal

Tell us more, thanks.

2 Likes

question about DAL , will the bakers’ non-participation in this program mean that they will receive 10% less reward? Is this reward fund formed from an additional quota like LB or will it be deducted from the rewards for staking and delegations?

if the rewards are included in the block rewards at the protocol level, don’t you think that the rewards for bakers in terms of delegation rights have already been cut by 1/3 and it enought? I, as a tiny baker, just don’t understand why I support the network if it doesn’t motivate me financially.

5 Likes

I think that reducing the cycle time to 1 day is not smart at the moment, it would be better if the cycle lasted 2 days instead of 2.8. In any case, in other updates we can reduce the cycle time if necessary. It is advisable not to cut it so much at once.

3 Likes

I am also interested in the question of stopping LB. Why is this not in the current proposal? In my opinion, everyone has come to the conclusion that it is high time to abandon LB.

4 Likes

There are advantages to keeping the unstaking period at 11 days that are being overlooked. If you significantly reduce the number of unstaking days, you disproportionately benefit stakers over delegators making staking much more “liquid”, especially considering the recent increase in the percentage of rewards of staking over delegating.

4 Likes

Do the involved parties still think that Agora is a good place for this kind of discussion? We would be much better off using Reddit…

2 Likes

“Upon reevaluation of the risks, we have revised our guidance and no longer recommend against deploying the DAL node on the same machine as the baker node.”

“The initial concern was that an attacker with access to a DAL node’s RPC endpoints could exploit a target baker’s IP address to launch a Denial-of-Service (DoS) attack. However, this risk is deemed low compared to other vulnerabilities inherent in public machines. Moreover, as the network expands and more nodes join, the risk is expected to diminish further due to the increasing complexity of mapping bakers’ identities to IP addresses.”

3 Likes

However, this risk is deemed low…

That doesn’t mean zero. Is the risk acceptable? Isn’t it up to the operators to decide?

NOTE: I’ve read it before—no point in reposting things that have already been shared here. There are already too many unanswered questions at this point.

3 Likes

Does latency matter for DAL?

In my case I am based in bangkok and singapore would be ideal hosting location for me, but everything there is 2x the price compared to eu

Would it be okey to run DAL in eu from my location?

Is there way to measure DAL performance?

6 Likes

I actually have a very simple docker stack file (similar to compose) that I recently shared with the team. I think they will put it up in the docs somewhere. DM me on Bluesky or Discord and I’ll share it with you. Not that it can’t be public but a little noisy in here :sweat_smile:

Regarding the PI stuff get a m2.nvme hat (I got one with PoE also which is nice!) and a m2 disk. I get about 1GB/s on a 2TB disk. More than enough an quite cheap.

I don’t know what the load will look like when it starts getting heavy use, but the PI5 with fast disk kan pull alot of weight! Full node + baker + accuser + dal node is hardly noticeable :muscle:

4 Likes

The necessary and cool nature of these changes to the Tezos protocol (as part of Tezos X roadmap) are somewhat being overshadowed by asking bakers to do more for less.

Bakers are being asked to run another service, which may theoretically reveal their home or business location, unless they’re willing to redo their setup at the cost of running another machine. If they don’t, they get 10% less rewards. For many small bakers the 10% penalty is probably less than the VPS subscription cost. $5 per month for a VPS costs around $60 per year. If someone is privately baking with just a single roll, that’s a big difference in the value prop of running a home bakery. Not everyone is super-techy and able to do this themselves on the cheap (ignoring man hours to actually set it up).

The cycle decrease of 2.8 days to 1 day seems like a natural and necessary change but it too has some considerations like having to pay higher fees for delegator payments since we’re going from around 126 payments to 365 payments per year. Also, some bakers will now have to calculate 2.8X of transactions for tax reporting purposes, resulting in higher subscription fees to reporting services and such, where the difference between reporting 500 transactions vs 5000 transactions is 5X the cost of the service.

The first concern above doesn’t really have any way around it. It’s an extra thing to pay for (in some cases) vs. incurring a concensus fine. For the latter concern, baker payment software can be adjusted to aggregate cycles and pay in bulk. To that end, TezPay already supports paying multiple cycles in bulk. We would just need to add this option to continual payments mode.

I get both sides of the argument here. The truth of the matter is that we may need to shed some small bakers in order to truly optimize consensus to the point of sub 3-5 second block times. And we do have to ask bakers to run DAL because it’s paramount for the L2 success of TezosX.

Perhaps the way to put a smile on this situation is changing the 10% penalty to a 10% bonus. Perhaps it’s setting up a Tezos Ecosystem DAO fund for small bakers. I know the fear is always that someone will setup 50 small bakers and take advantage of whatever benefits and to that I just have one thing to say–good. If someone is going to go through all this effort and obfuscation just to get rewards that would be meaningful to small 1-2 roll bakers, let them.

It’s easy to lose track of the concerns of the small bakers, not support them, lose them and lose the cypher punk bragging rights that came along with it. We’ve already shed 50 small bakers when Paris activated, going from around 350 bakers to around 300 and we didn’t bat an eyelash, in terms of doing anything about it. A few more changes like that and we’ll be looking at fewer and fewer bakers.

12 Likes

I’m not sure, several folks are actually running a DAL node on Ghostnet using tezbake already - -This one is for @Primate411 and co. :slight_smile:

4 Likes

How delegator rewards are distributed is indeed and off-chain agreement, and already some public bakers don’t pay delegation rewards immediately, but keep 5 or 7 cycles delay. For instance, a public baker whose name shall remain redacted has recently told me they keep 7 cycles for one of their bakers to have margin e.g. when there is a protocol upgrade and reward distribution tooling might be delayed.

As for batching, some small private bakers I know this manually and group reward allocation monthly (and in their own blocks).

Don’t think this sounds complicated to add to tooling like tezpay or trd – Thoughts, @Primate411 ?

5 Likes

Indeed GermĂĄn, TezPay has the ability to manually batch payment cycles and we can work on the ability to convert the continual payment functionality to dovetail with that to bring feature parity.

7 Likes

Currently, my impression is that bakers and stakers are essentially subsidizing immediate staking rewards (newly staked) before new stakers contribute to baking power. The rewards are diluted from the current stakers (similar to overdelegating or tax). The promise was that older stakers would make that amount back after newer stakers unstake funds for the equivalent period before finalizing unstake. If the cycle is reduced to 1/3 the previous duration, doesn’t that cause an imbalance in that previous stakers will only reclaim 1/3 of these prepaid rewards that were staked before the ‘R’ protocol (assuming new ‘R’ cycle rewards will be worth 1/3). If so, this supports keeping the current unstaking duration at 11 days, or another method is required to reimburse potentially lost funds.

2 Likes

I use tezbake on my ghostnet setup and am now running a dal node remotely.

What I did.

On the remote, the old docker-compose:

services:
  dal-node:
    image: tezos/tezos:octez-v21.1
    restart: unless-stopped
    entrypoint: sh -c "octez-dal-node run --endpoint=http://node:8732 --attester-profiles=tz1T1jwPTXSA5kfBB9WFYgj3uW2XirqPq384"
    ports:
      - 127.0.0.1:10732:10732
    volumes:
      - /data/docker/ghostnet-dal-node:/home/tezos

  node:
    image: tezos/tezos:octez-v21.1
    restart: unless-stopped
    entrypoint: sh -c "octez-node run --config-file=/var/run/tezos/node/config.json --rpc-addr 0.0.0.0:8732 --allow-all-rpc 0.0.0.0:8732 --history-mode rolling:2 --force-history-mode-switch"
    volumes:
      - /data/docker/tezos-ghostnet/:/var/run/tezos/node/
      - ./client:/var/run/tezos/client
      - ./snapshot:/snapshot

Created a user, set up ssh key based authentication.

On the home baker, just added the --dal-node config like specified in the bakebuddy docs.
Ran the ssh tunnel with: ssh -L 10732:127.0.0.1:10732 ghostnet@myremoteserver

I will setup autossh when I’m less lazy so that it auto-reconnects when the ssh session drops.

6 Likes

Thoughts:

  1. Any chance for smart_rollup_challenge_window_in_blocks to be reduced? Does it really take 2 weeks to calculate an alternative commitment as part of the refutation period? Withdrawal delays for sending XTZ back to L1 are a major UX issue for Etherlink

  2. As some have said here, the liqudity baking reward could be used more productively either via the DAL, or to provide liquidity for a replacement reward scheme for Etherlink users as their tez is effectively undelegated, they have no voice in the L1 ecosystem, and they are diluted due to inflation

4 Likes

Is there a list of these? Previously smaller changes didn’t receive any opportunity for community discussion or scrutiny - eg the switch from delegator rewards based on snapshots to min_delegated_in_current_cycle which had unintended consequences (eg on Kolibri vault rewards)

3 Likes

I love Etherlink and would like to support it’s growth in anyway possible. As a home baker utilizing tezbake, I hope the set up of all this is made easy in layman’s terms. I manually compute rewards, the 1 day cycle will be an increase in accounting efforts(unique to me). The 3 day activation period, I would like to see that doubled to 6 for cases of natural emergency etc.

3 Likes

1 day cycles instead of 2.8 days? I guess it has some benefits.
The only negative aspect i see is that i will have to pay out daily instead of every 3 days. Yes, i can automate it, but i like to know what’s happening. That’s why i still pay out manually.

On the DAL reward thing, i believe DAL is necessary for the vision we have for Tezos. So, is 10% rewards allocated to DAL enough? I don’t believe so. Is it equally as important as the layer 1? No. So 50% is too high. Perhaps 30% would be a proper fit?

4 Likes