Last week by the numbers
neptune-core
twenty-first
triton-vm
Neptune Happenings
Hard Fork Alpha Development
The primary development focus last week was again on Hard Fork Alpha, an update to the consensus rules designed to improve transaction throughput. This is achieved by enabling the reuse of the pre-processing step of the memory-hard mining algorithm. This change allows miners to switch to new block proposals almost instantaneously without losing valuable computation time, leading to faster transaction inclusion and healthier guesser fees. The hard fork is considered a top priority.
Hard Fork Activation Timeline
The hard fork for Neptune Core (version 0.5) is officially planned, though a specific activation block height has not yet been determined. The current target is a window of 4,000 to 5,000 blocks after the pull request is finalized and merged, which translates to roughly four to five weeks. The timeline is not set in stone and may be adjusted based on feedback from code reviewers.
Triton VM and Neptune Core Evolution
Planned modifications for Triton VM’s ZK-STARK proof system will introduce backward incompatibility, necessitating a hard fork for Neptune Core. While it’s difficult to predict exact figures before implementation, these changes are estimated to yield a performance speedup of 2 to 4 times. @jfs and @aszepieniec are collaborating on roadmapping the next steps for the Triton VM to ensure a smooth transition. The planned modifications are a major effort and will require multiple months to complete.
Triton VM Instruction Set Architecture (ISA)
The current Triton VM instruction set is considered robust, but it may require revisions to align with the new Stark engine. A preliminary decision is that existing instructions will not change their behavior in new versions of Triton VM in order to guarantee that smart contracts already built on Neptune Core do not break. Under this tentative decision, future updates will allow for the addition of new instructions but not the modification of existing ones. To signal its stability, Triton VM version 1.0 is planned for release soon, with any future breaking changes to be bundled into a subsequent version 2.0.
Performance Optimizations and Bug Fixes
A bug related to modular reduction in the vectorized version of Tip5 was reported by a user, then isolated, identified, and subsequently fixed by @jfs. The correction introduces a minor slowdown but ensures algorithmic correctness, which is the higher priority. To prevent similar issues, testing of all hash function implementations has been increased. We want to emphasize that this bug was not part of any release.
Optimizations like the vectorization of Tip5 and improvements to the scale function are expected to provide single-digit, and possibly low double-digit, percentage speedups.
Neptune Explorer Security
A portion of this week’s development time was dedicated to patching a vulnerability in the Neptune Explorer. The vulnerability was related to request throttling and the parsing of input URLs. A framework was also developed specifically to test the countermeasures and ensure the fix is robust.
Community Engagement and News
Recordings from @aszepieniec’s recent lectures in Colombia have been successfully downloaded and will be uploaded for public viewing soon. The team has also been participating in Twitter Spaces, with recordings potentially available for those who miss the live events. In ecosystem news, the DrPool mining pool, which was active on the old network, appears to have returned and is now supporting both CPU and GPU mining.
Reminder: 0.5.0 Feature Wishlist
A wishlist has been created for the next version of neptune-core. The team is soliciting community feedback, so please add your desired features on github, or just comment in this thread.
Contributor Updates:
- explorer.neptune.cash vulnerability and robustness
- finally locate, understand, and fix the AVX Tip5 bug
- improve testing for Tip5 (AVX and non-AVX)
- discuss next steps for Triton VM