Validator Node Verification Progress
Neo Core developers are making steady progress on ensuring that Council candidates actually operate functional nodes. This requirement is part of the broader effort to flatten GAS rewards across the network. The team is considering two main approaches, which I think both have their merits.
One option involves a lightweight proof-of-work scheme specifically for candidates. The other approach uses a staking and slashing model where candidates would need to lock up NEO and could face penalties if they fail liveness checks within certain timeframes. It’s worth noting that consensus nodes already demonstrate their liveness through view change behavior, so these new mechanisms are really focused on candidate verification.
Version 3.9.0 Development Status
The v3.9.0 branch is nearly complete according to the developers. They discussed including arbitrary message signing support that was ported from Flamingo, but this might get pushed to a later release. The functionality depends on an additional pull request and clear specifications for signed message semantics, so if the documentation isn’t finalized in time, it might have to wait.
One item that definitely won’t make it into v3.9.0 is NEP-25. Planned changes to this standard are expected to delay development by one to two months, so contributors agreed to defer it rather than hold up the entire release. Sometimes you have to make these tough calls to keep things moving forward.
Testing and Review Processes
Execution fee factor changes and whitelist-based free transaction support have already been merged for v3.9.0. The team is creating a dedicated test checklist for these features before publishing the final binaries. They’re encouraging broader review from multiple contributors, especially for pull requests that affect protocol-level behavior.
This approach makes sense to me because it helps reduce the risk of divergent behavior across explorers, wallets, and alternative node implementations once the update goes live. Having multiple eyes on these changes can catch issues that might otherwise slip through.
CryptoLib Design Improvements
Developers also examined the proposal for Ethereum-compatible BLS support in the CryptoLib native contract. They identified some concerns with the current approach. The new methods operate on byte arrays, while existing CryptoLib functionality exposes BLS points through interop interfaces with dedicated serialization helpers.
The repeated serialization and deserialization for each operation seems inefficient and inconsistent with the current API design. The preferred direction is to align Ethereum-compatible BLS support with the established interface style by adding serialization methods for the Ethereum format while executing operations on internal BLS point representations.
Governance Mechanism for Blocked Funds
The group reviewed a governance change that would allow the Neo Council to move funds out of blocked accounts after a defined period, requiring 19 of 21 signatures. This mechanism is intended for cases where funds are frozen in malicious or compromised wallets.
It’s important to note that this isn’t meant to recover assets for users who have lost private keys and can’t prove ownership. There will be a vote to determine the default blocking period, with options like six months, one year, or two years. Once finalized, this feature should provide a clearer process for handling sanctioned addresses.
Overall, the development team seems to be making thoughtful progress across multiple fronts, balancing new features with necessary testing and design improvements. The careful approach to protocol changes and the emphasis on broader review suggest they’re taking the stability of the network seriously.
