Guideline: Runtime protocol changes

[evgenykuzyakov]

Motivation

This doc explains the guidelines for protocol changes in Runtime. Which changes should be included as a protocol change and which changes shouldn't. Please add and comment on the guidelines. We can later generalize this doc from Runtime specific to NEAR specific.

Protocol changes guidelines and requirements

This requirements are mostly for new features of the protocol. Bug fixes and corrections should be evaluated differently.

The change can not be implemented with the existing API

If the change can be implemented with the existing API, it shouldn't be part of the protocol.

Examples:

• Staking delegation was implemented through a smart contract instead of core protocol, because it was possible to do.
• keccak256 and keccak512 were possible to implement on the contract level, but the gas metering for every call was incredibly expensive, so it wouldn't be possible to use in the intended merkle-path proof application. That's why it was moved to the native support within a protocol

The change should solve general use-cases

The change should not be limited in functionality. When looking at the proposed change always think whether it's possible to solve with more generic solution.

For example a change to support token transfers can be generalized to generic resources transfers, that can be generalized to Safes with resolutions (#26). But even Safes are not generic enough, because they don't allow claiming the underlying resource and can only be dropped or transferred back to the owner's contract. (That's why we're working on a more generic sharded version).

The change is critical for the success of the network

Protocol changes are not free. They require a network upgrade and come with the debt of future maintenance. Some changes solving general use cases and can't be done with the current API, but may not be critical for having them available.

Examples:

• Private transactions. They are not critical for the success of the network right now, but they become a feature of most modern blockchains that support monetary transfers. While it's arguable whether we should include them on the protocol level, it makes sense to support native math on the protocol level similar to hashes, because it's impossible to implement it on the contract level with our current gas metering infrastructure.
• Safes can not be implemented without protocol changes, because a safe is required to be atomic and need to have a callback on the resolution. Also safes solve generic enough use-case such as auto-unlock mechanism. But Safes are not critical enough right now, because majority of token and exchange operations can be implemented with the existing API.

The change has a high priority right now

Our engineering resources are limited and every change requires careful review. That's why the change has to be a high priority in order to be implemented and included. This item is somewhat similar to the previous one, but more reflect a time urgency than the long-term requirement.

Examples:

• For example we know that we need to support common contract code ([Discussion] Shared global key-value storage #93), since accounts are required to pay for the storage of the contract. And some contracts might need to be deployed on a lot of accounts, e.g. for air-drops support. But there are some changes that have higher priority right now and this one can wait.