In an effort to increase general awareness of community-driven development progress on the NEO platform, NEO News Today aims to produce a monthly report of noteworthy updates. The reports will include both contributions to the NEO core, and improvements made to community-created projects.
These reports will not contain an exhaustive list of all development. NEO News Today endeavours to compile progress from as many community contributors as possible, but not everything can be included due to the nature of gathering and summarizing this information.
Any NEO developers—whether part of a development community or otherwise—that have made significant contributions to NEO infrastructure or development tools are encouraged to contact NEO News Today at email@example.com with relevant information for future reports.
NEO Protocol Contributions
Since October 24th, NeoResearch members Igor and Vitor Coelho have been working on a major update that aims to optimize NEO’s consensus mechanism. The proposal has also seen notable contributions and reviews by members of City of Zion and NEO Global Development.
The first part of this update is covered by PR #426, and will focus on the addition of the ‘commit’ phase of consensus to prevent the ‘fork’ issue (ported to be compatible with the Akka model), along with a regeneration strategy and other performance optimizations. The regeneration strategy aims to allow lost/failed consensus nodes to automatically reconnect with the network, avoiding the need for restarts.
The initial changes have been completed and are currently undergoing testing by NeoResearch, NGD and CoZ. A new neo-cli release featuring these changes is expected to be pushed to TestNet consensus nodes in the near future.
Neon Wallet (CoZ)
November saw the release of Neon Wallet v2, a complete design overhaul of the original Neon Wallet. A large number of changes were made across the month, including the implementation of new features such as NEP-9 QR generation, node selection and simple, toggleable priority fees for transfers and token sales.
The first week was spent bug fixing new features and other assorted quality of life improvements, such as an increase to the max number of transfer recipients from 10 to 25. Due to the Neon Wallet project goal of decentralization, dependencies on other projects have been removed. One example of this is the reliance on Neoscan for automatic node selection, which was replaced with an automatic node selection algorithm built directly into the Neon Wallet.
The wallet release surpassed 15k downloads within the first week. Short term goals at this point included dealing with minor bugs, improvements to testing and considerations for alternative pricing data APIs. The team also began planning support for localnet or manual node address entry, multisig wallets and an improved UX/UI for GAS claims.
The final week saw over 20 issues being resolved and closed, with further improvements made to test coverage and the node selection algorithm. This will remain as the core focus for the near future, as the team continues to lay a solid foundation for the first major update, designated v2.0.1.
The majority of November’s development has been spent improving and updating the command line interface (CLI). One of the first improvements was the addition of a destroy command, allowing service containers to be stopped and removed as needed. Version 0.11.1 of neo-local was released on Tuesday, November 6th.
The second week, starting Monday 12th, saw the PrivateNet container, neo-python and notifications-server services being added to the CLI. Progressing the CLI is hoped to simplify the understanding and set up of a personal NEO blockchain for development.
In the following week beginning Monday 19th, the neo-scan-sync and neo-scan-api container were both added to the CLI, alongside the addition of other improvements such as the ability to bootstrap the chain. Feature work was started on the CLI which aims to make it contextually intelligent; meaning it knows which services are dependent on each other so that they are started in the correct order.
The final week of November saw improvements to CLI elements that had been developed quickly during the early stages of the project. These changes include increased flexibility for configuration, and support for loading configurations on any operating system. An improvement was also made that provides progress bars and other information to help a user know how long a download will take.
The neo-local project was also used by the recent European hackathons (Rotterdam, Berlin and Zurich). The team reported that it had received lots of useful feedback on how to improve the project in the future.
Although the neo-python nodes typically work without issue during normal network activity, increased usage/abuse could cause neo-python nodes to become stuck, requiring restarts. The neo-python team has spent time analyzing this behaviour and updating the network code to improve the overall resilience of these nodes.
Improvements were also made to the bootstrapping process, which previously required users to update the bootstrap link in the protocol.xxx.json file. The file will now dynamically lookup the latest version, so that users are not required to make manual modifications. The MainNet and TestNet bootstrap files have been updated, to block heights 3002xxx and 2022xxx respectively.
The implementation has also been updated to allow component classes to be swapped out by specifying a path in the neo-python settings. Although currently only the RPC and REST server are supported, the team intends to expand this to include CLI commands, networking and databases. Eventually, the team hopes to allow users to create self-maintained plugins that can be installed via the pip package manager, then activated with a change to protocol.xxx.json.
The neo-python project is moving closer to feature parity with neo-cli, following the addition of GET and OPTIONS request functionality to the JSON-RPC servers. Following the update, RPC nodes using neo-python will be queryable via GET requests.
Neo-tools is a more recent project, headed up by City of Zion developer Fetter. The implementation takes the form of a CLI, which aims to bring all NEO APIs, examples and project primitives into one place so they may be easily accessed by developers in a simple, Unix-like environment.
Fetter began with an initial build that included basic reference API implementations and services. Among these included CLIs for Neoscan, neon-js, Binance, Coinmarketcap and CoinPaprika. Following these inclusions, Fetter prioritized on reactively adding whatever tools were most heavily required or requested by other members of the developer community.
In the short term, updates to neo-tools will focus on consistency and code modularity, but looking forward Fetter aims to include the full range of NEO services, including RPC and REST APIs, wallet services, and blockchain metadata analysis/transformation utilities.
NeoCompiler Eco (NR)
NeoCompiler Eco is a smart contract development platform, created by the NeoResearch team to allow them to compile NEO contracts using Linux-based systems. Accessible through a web browser or mobile device, NeoCompiler Eco can help developers to build, test and even deploy smart contracts written in C#, Java, Python and Go. The compiler operates on a shared private test network that resets every 12 hours, allowing anyone to test out their contracts before deploying to MainNet.
NeoResearch is currently focused on implementing the consensus-draw tool, which aims to track consensus data and present it in a format that can be easily understood by humans. The implementation of this tool could also help debug any potential issues with NEO consensus.
Smart Account Composer (NR)
The Smart Account Composer, or Smacco, is another NeoResearch project that allows the creation of NEO addresses with added functionality. Instead of generating a typical public/private keypair with basic send/receive functionality, Smacco allows users to create verification contracts with specific rules.
These logic-based conditions can be used in multiple ways, such as for the creation of wallets that require multiple private keys to unlock, or to lock specific actions behind a timestamp. It can also be used to allow specific private keys the ability to use certain actions, such as sending a specific token, without giving them full control of the account.
As with NeoCompiler Eco, user accessibility is a high priority for Smacco. To make it easy to understand the flow of logic described by these rules, any smart account created with the tool is accompanied by an automatically generated logic diagram. These diagrams are designed to be easy to understand by anyone, regardless of technical proficiency.