Tell us more, thanks.
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.
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.
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.
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.
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âŚ
â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.â
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.
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?
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
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
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.
Iâm not sure, several folks are actually running a DAL node on Ghostnet using tezbake already - -This one is for @Primate411 and co.
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 ?
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.
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.
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.
Thoughts:
-
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 -
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
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)
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.
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?