in

[Nano’s founder Colin LeMahieu] New scheduler and prioritization design based on the TaaC and PoS4QoS proposals. It has the potential to remove PoW requirements largely or entirely. It will set Nano apart from all the other systems that view fees as the only solution to the scheduling design.

[Nano’s founder Colin LeMahieu] New scheduler and prioritization design based on the TaaC and PoS4QoS proposals. It has the potential to remove PoW requirements largely or entirely. It will set Nano apart from all the other systems that view fees as the only solution to the scheduling design.



View Reddit by rrdonooView Source

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

GIPHY App Key not set. Please check settings

17 Comments

  1. **Forum bot:**

    I’ve added a branch: GitHub – nanocurrency/nano-node at election_scheduler 47, which is the start of an election scheduler component that will replace how elections are currently started. This will allow a separation between the decision of which elections to prioritize and the mechanics of tallying elections. Encapsulating prioritization this way makes the scheduling decision process easier because the site requesting the election to be started doesn’t need to evaluate all other scheduling considerations.

    Elections are currently started in the node by the following sources:

    * Live blocks off the network
    * Confirmed dependents – when the previous block, and on receives the send block in the link field, are confirmed, the successor to that previous block can be activated if already in the ledger
    * Higher block difficulty block rescheduling – when higher work is published for an existing, unconfirmed block in the ledger which doesn’t already have an election
    * Vote observation hinting – when a % of the voting weight is seen for an unconfirmed block in the ledger which doesn’t already have an election
    * When requested through the block_confirm RPC command

    With the new scheduler component in place, all these sources will feed to a central list of eligible elections so their prioritization can be more accurately compared across all elections. The aim of this approach is to provide better control over which elections are being started so one particular trigger doesn’t dominate the resources. The ultimate result should be better election alignment across the network.

    This branch also contains the start of an election prioritization scheduler which will start elections based on a combination of the account balance and the last time the account had activity. Separating accounts into balance tiers prevents scheduling starvation of any tier by any other tier.

    The foundation for this design is from the TaaC and PoS4QoS proposals by @Rob with some modifications to support malleable and untrusted timestamps. While signed timestamps give more mathematical rigor to the scheduling algorithm, it would require changing the signed block contents, coordinating network upgrades, and would take several months or more to implement which doesn’t fit with the current tactical needs.

    The scheduler will start elections for the highest priority accounts in each balance tier in a round-robin fashion and the priority within each tier is least-recently-used order for the respective account. There will be 128 balance tiers, one for each bit in the balance field, and the leading 0s in the balance will determine the bucket.

    The new scheduler will consider the following:

    * Priority scheduled accounts
    * Confirmed dependents
    * Vote observation hinting
    * When requested through block_confirm
    * Fork resolution – This separation allows forks to be cleanly separated into their own low priority tier.

    Of note, the new priority scheme has the potential to remove PoW requirements largely or entirely. This will make nano integrations far simpler than they currently are and sets nano apart from all the other systems that view fees as the only solution to the scheduling design.

  2. I’m really excited for this and I hope it happens. It’s a cool concept if I’m understanding it correctly. Game changer for sure. Waiting for the people to come and talk about #112 or spam or something though like always. I’m here for it. NANO = HODL

  3. It’s going to be interesting to see which approach brings Nano to the next level and if their solutions can be applied to other cryptos as well and potentially help change the landscape for those that may be susceptible to spam or denial of service attacks.

  4. I will keep my nanos for now (mostly because I would lose so money if I do), I really hope this will turn the tide for Nano.

    Utimately I love the product so fingers crossed!

  5. I hope they can resolve this spam situation. I know people on this sub hate Nano but it is genuinely the only crypto I’ve used that isn’t some kind of pain in the ass, so it deserves to succeed imo

Loading…

0

What do you think?

Don’t sell the tip to buy the dip.

The DeFi Token Plunged 80%

Fake Bitcoin Sellers Steal Close to $500K From Victims