Topic: Forging Delegates in DPOS (Read 75 times)

Thanks for your feedback

1.  You have to evaluate the real risk of your delegates agreeing on a 51% attack. Are they institutional delegates with clear ownership that are less likely to get themselves into trouble or does the system really need to be completely trustless with a huge degree of "distrust". If you delegates are not really likely to agree on an attack and are identifiable, you can probably do with less.

You bring up a good point.  Initial I suspect delegates will not be institutions and should not be trusted.

2. When planning a 51% attack each of the 26 delegates would need to trust the other 25 because if they fail on their attack they will loose their stakes, thus...How high are the stakes? How much risk will those malevolent nodes have for themselves if they try an attack?

Another good point.  Initially the stakes won't be very high, but over time as our coin becomes more valuable the stakes for each delegate will increase accordingly.  One way we can hedge against the initial risk of small stakes is by voting with our development fund until the network is substantially decentralized.

3. On the practical side: If you are going to make it from 3 days or 6 months to 1 minute, does it matter if it takes 2 minutes (or 4 or 5) for your particular case? Normally I would say no unless you are planning an exchange, and in that case you most likely need a centralized component on the system.

Even with an exchange the blocktime doesn't matter that much because there will need to be a centralized frontend portal for real time transactions, with batch settlement happening on the chain in the backend.

4. What time confirmation differences you have with 50, 100 and 200 delegates? Have you made accurate numbers?

~8 Second blocktime with 51 ~10 with 101 and ~15 with 201.  These numbers come from some other lisk based DPOS projects

When systems are "semi-decentralized" the risk is very clear. Regarding that with 101 more people have a chance to forge, with 51 you need 26 of 51 to make a successful attack, but you will need 51 malevolent delegates to fully confirm with 101. It is the case that more people would need to agree to succeed on an attack.

Considerations:

1. You have to evaluate the real risk of your delegates agreeing on a 51% attack. Are they institutional delegates with clear ownership that are less likely to get themselves into trouble or does the system really need to be completely trustless with a huge degree of "distrust". If you delegates are not really likely to agree on an attack and are identifiable, you can probably do with less.

2. When planning a 51% attack each of the 26 delegates would need to trust the other 25 because if they fail on their attack they will loose their stakes, thus...How high are the stakes? How much risk will those malevolent nodes have for themselves if they try an attack?

3. On a the practical side: If you are going to make it from 3 days or 6 months to 1 minute, does it matter if it takes 2 minutes (or 4 or 5) for your particular case? Normally I would say no unless you are planning an exchange, and in that case you most likely need a centralized component on the system.

4. What time confirmation differences you have with 50, 100 and 200 delegates? Have you made accurate numbers?

Be cautious when putting links to your project on this section, you may anger some members.

I am the CTO of a new DPOS project called SWAPBlocks.  We have recently shifted our DPOS blockchain from Lisk source code to Ark.  We had planned to have an initial 101 delegates, but some of the members of the discord channel have said they prefer 51 due to the quicker block times.

We are building a platform to automate many of the back-office task associated with asset transfer that can take anywhere from 3 days to 6 months today.  SWAPBlocks non-blockchain component will significantly speed up the transaction times by eliminating many of the inefficiencies in asset management processes today.  The blockchain layer is used for settlement, data-integrity and lineage.

Benefits of 51:

Faster blocktimes
Updates can be pushed out with less effort than with 101 (only 26 delegates need to upgrade nodes in order for change to be implemented)
Less code changes are needed for the initial clone

Benefits of 101

It's slightly more decentralized
More people will have the chance to forge

We've also got a poll here:
https://strawpoll.me/15775335


Check out our website to learn more or join the discord:

http://swapblocks.io
https://discord.gg/Ypa7fCN