As luck would have it, Public Node’s first protocol vote will be on proposed Stellar Core version 13.0. Public Node, along with all other entities running Stellar validator nodes, must decide whether to adopt, or not, the proposed Stellar protocol change.

Being that this is Public Node’s first vote, let’s spend a little extra time explaining the Stellar protocol and how it is improved before jumping into the specific changes being proposed.

What is the Stellar Core protocol?

The Stellar Core protocol (“Stellar protocol”) is the software program that includes all the rules, operations, and procedures that establish how the open Stellar network will run. It defines specifics such as how often transactions will be processed and implements the method used to reach consensus among a group of independent entities – such as agreement on who paid whom.

Stellar Core is the program nodes use to communicate with other nodes to create and maintain the Stellar peer-to-peer network. It’s an implementation of the Stellar Consensus Protocol configured to construct a chain of ledgers guaranteed to be in agreement across all participating nodes at all times.

Always room for improvement

As with most people-made things, there is often room for improvement or, at the very least, a need to update for external factors such as changes in technology and human behavior. This reality is just as true for the Stellar protocol as it is for an automobile. However, unlike improvements to an automobile, which can be unilaterally made by its manufacturer, improvements to the Stellar protocol must be agreed to by many. This is because the Stellar protocol is run by many different entities that collectively make the Stellar network.

Reaching agreement on which Stellar protocol to collectively run is managed by making a publicly viewable proposal called a Core Advancement Proposal (CAP). A CAP details the motivation, specific code changes, rational, backwards compatibility, and security concerns of the proposed change. Entities running validator nodes, like Public Node, then decide to either adopt, or not, the proposed change until all, or nearly all, agree on a unified path forward. For the most part, CAPs are just that, “advancements” and have historically been adopted without any fuss by the entities running validator nodes.

What protocol changes are in Stellar Core 13.0?

Below is a layperson’s explanation of the changes being proposed in Stellar Core protocol version 13.0. For all the details down to the line-by-line code changes, visit Stellar Core’s Github release page.

Explanation

CAP-0015 Fee-Bump Transactions

CAP-0015 would allow anyone to pay an existing transaction’s network fee. Have you ever been in a situation where you waited in line to purchase something only to find out that you didn’t have quite enough money to pay for it?

Then a nice person in line behind you helps you out and makes up the difference. That’s basically what this allows, but for Stellar transactions.

If adopted, it avoids a lot of unnecessary hassle associated with canceling a transaction and resubmitting it with additional funds to pay for fees. This may not seem like such a big deal if a single entity is involved, but imagine if it was a transaction that required signatures from many entities and the insufficient funds an amount less than a cent.

A significant motivation behind this CAP is that it would allow validators to increase the minimum transaction fee without fear of forever stranding existing transactions that were built assuming a lower minimum transaction fee.

Another interesting benefit described in the CAP is one where an entity, such as a game developer, wants to manage the fees for its players. This CAP makes that a whole lot easier to do.

CAP-0018 Fine-Grained Control of Authorization

CAP-0018 would provide asset issuers more granular authorization control to accounts that hold their issued asset. As of now, asset issuers must work within an on/off construct where its either: 1) an account cannot hold the asset; or 2) an account is fully authorized to do anything and everything with the asset.

The lack of middle ground leads to complex workarounds and other complications that could be avoided with the ability to assign more granular action-specific authorizations. This is not unlike being able to turn off the electricity in a single room of your house as compared to using the main breaker to turn off the electricity for every room in the house.

CAP-0027 First-Class Multiplexed Accounts

CAP-0027 is a big deal for mainstream users of Stellar in that it could forever end the pains caused when a memo is required but forgotten or input incorrectly.

Rather than use a unique stellar wallet address for every account, many exchanges chose to assign multiple accounts to a single wallet address. To distinguish funds among the different accounts assigned to that single wallet address, exchanges require that the optional memo field be used to identify which of their accounts should be credited with the sent asset.

This has created significant problems when a memo isn’t included because it is the same as sending cash to your local bank with no other directions. What would your bank do if you mailed in cash with no other information?

CAP-0027 allows a wallet address and a memo to be combined together into one standard stand-alone 56 character Stellar wallet address. This feature allows an entity to create multiple Stellar wallet addresses for each of its users without actually having to manage more than one Stellar wallet.

As good as this is, there are some potential complications listed in the “security concerns” section of the CAP. In short, having multiple wallet addresses associated with a single wallet could confuse some client software or be used to circumvent wallet blacklist screens. It could also lead to unintended (but avoidable) parsing errors.

Lastly, this CAP allows for multiplexed accounts, but alone does not make them available. CAP-0027 will need to be combined with approval of a separate Stellar Ecosystem Proposal (SEP), Software Development Kits (SDKs), as well as adoption in general, before we see multiplexed accounts being used.

CAP-0028 Clear Pre-Authorized Transaction Signer on Failed Transactions

Stellar allows transactions to be pre-authorized. An example of a useful application of this feature is with escrow accounts where two different transactions can be pre-authorized but only one can be used.

The pre-authorized signature is automatically removed from the source account if the transaction succeeds. But, if the transaction does not succeed, the signer is left on the account and must be manually removed. CAP-0028 would remove the signer from the source account when the transaction is being applied, regardless of the outcome of that transaction, so that no manual removal of the signer is necessary.

CAP-0030 Remove NO_ISSUER Operation Results

There are operations that unnecessarily load the issuer, and return an error result if the issuer of an asset was not found. These errors are not necessary, and CAP-0030 aims to remove them.

Ready to vote?

The Public Node vote is open through May 24th 2020 as determined by Coordinated Universal Time (UTC). Head on over to our vote page to cast your vote.