Stellar Dev Digest: Issue #22

Stellar Community Fund Round 3, New Implementation of Stellar Core, Fireside Chat w/ Jed McCaleb & Denelle Dixon.

Published in

Stellar Community

7 min readNov 18, 2019

Hey everyone! Welcome to another issue of the Stellar Dev Digest, a weekly recap of all things related to the development of the Stellar Network.

What is Stellar? Stellar is a platform that connects banks, payments systems, and people. Integrate to move money quickly, reliably, and at almost no cost.

Featured Developer Posts and News from the Week

🏆 Stellar Community Fund Round 3 guidelines are out! Reminder: SCF supports independent developers by awarding lumen grants to projects based on a community vote. This round, 3 million lumens will be split proportionally among 8 lucky — scratch that — industrious winners. If you’re interested in participating make sure to submit your project by December 14 @ 12:00PM PST.
SFBW19 — Fireside Chat: Jed McCaleb & Denelle Dixon — Jed and Denelle recently attended San Francisco Blockchain Week where they had a fireside chat with Ronen Kirsh from Dekrypt.
👾 StellarExpert adds identicons! Lobstr introduced them to the Stellar ecosystem a couple months ago with the hopes of adding personalization to public keys. Take a look at any address on StellarExpert to see them in action.
Lobstr rolled out a big update that includes localization. The app now supports English, Spanish, Korean, Russian, and Thai, and they’re planning to add more languages soon. They’ve also created a new onboarding tutorial and more — Read about the update here.
️StellarX adds a ‘notional balance’ feature to user dashboards.
Lumenthropy now supports CosmicLinks. Cosmic.link provides a convenient way to share Stellar transaction requests as a URL, allowing Lumenthropy visitors to donate in a few clicks.

This week I’m highlighting Astrocore from the Evil Martians team! They’ve been featured on Dev Digest before, but this time we are going more in depth.

In short, Astrocore aims to become an alternative, Rust-based implementation of stellar-core, the core component of the Stellar network. Why does the ecosystem need another implementation of Stellar-core? And why Rust? Great questions!

Lucky for us, the team working on Astrocore answers them really well in their README:

Why another implementation?
Stellar itself is a blockchain, decentralized by nature. Having more than one core node implementation is right for decentralization. Also, reimplementing can help to discover possible bugs in the current codebase.

Reference implementation doesn’t have any specification of how it works, so we are going to use the reverse engineering approach and kickstart specification writing process (check out Github wiki). Having one facilitates the creation of other implementations tremendously.

Why Rust?
The Rust language seems perfect for this task because it focuses heavily on performance and reliability. Moreover, Rust code is developer-friendly, and this can help to increase the number of potential contributors.

If you’re interested in the specs, you can find those here: https://github.com/astroband/astrocore/wiki

Talking to the Team

I also got a chance to ask one of the developers, Sergey Nebolsin, about their experiences so far, and about how to get involved. Here’s what he had to say:

I was thinking about your questions and in fact it all comes down to the lack of (semi-)formal specs of pretty much everything except for the data encoding (XDR) and consensus protocol (SCP). There’re a few pieces of documentation here and there, but it’s partial and “decentralized”: docs folder, src/<subsystem>/readme.md files, and just regular comments, like this one. For newer development we usually have a decent spec in the CAPs, but they still describe individual features, and there’s no single place which specifies how it all works as a whole system and defines the rules you have to follow in order to be compatible. The only ultimate specification is the C++ code of the stellar-core itself.

While building Astrocore we started to collect all our findings from different docs, the source code and actual testing against the testnet, and we came up with the (early and incomplete) draft of the Network/P2P layer spec, which you can find here.

The ultimate goal is to move from “The Stellar network is what stellar-core’s C++ code implements” to “This is the specification of the Stellar network. Full implementations: stellar-core (C++). Partial implementations: astrocore (Rust), stellar-core-go (Go), …” :)

We would love to see more involvement from the community into this process of creating the Stellar network specs, and we’re also open to any feedback and suggestions on how to better organize this process: what’s the best place to keep the specs? Stellar-protocol repo? Other independent repo? Public wiki? How do we make sure that new material is being reviewed in a timely manner and doesn’t stuck as a draft forever? etc.

Updates to Stellar Protocol (CAPs) and Ecosystem (SEPs)

Core Advancement Proposals (CAP) and Stellar Ecosystem Proposals (SEP) are a formal way of documenting proposed standards to improve various aspects of the Stellar Network. These function similar to EIPs and BIPs from the Ethereum and Bitcoin communities respectively. CAPs and SEPs represent the culmination of many discussions that often take place on the Stellar Developer Google Group.

The two SEP changes this week include clarifying SEP-0024’s title and deprecating SEP-0003.

[SEP-24] Clarify Title — change title from “Simplified Anchor/Client interoperability” to “Interactive Anchor/Wallet Transfer Server”
Deprecate SEP3 — due to lack of business need, SEP-0003 has been deprecated and SEP-0024 is now recommended instead.

If you’re interested in some of the ongoing conversations around other ecosystem proposals don’t hesitate to follow along and contribute. Here’s some of the latest discussions, most of which delve into the hot topic of how to make user onboarding easier:

We had a pretty big CAP update last week, so this week is going to be pretty chill in comparison. Only one PR was merged, CAP-0025 updates. The original information included in CAP-0025 had a few simplifications that have now been addressed by SDF Developer Marta Lokhova.

Calls for Participation

Want to contribute to Stellar but don’t know where to start? The repositories below have a handful of beginner friendly PRs for you to take on!

Kelp (Go: 9 Open Issues): a free and open-source trading bot for the Stellar universal marketplace.
Account Viewer (JavaScript: 5 Open Issues): a simple tool to view an account on the Stellar network and make transactions from it.
JavaScript SDK (JavaScript: 8 Open Issues): a Javascript library for communicating with a Stellar Horizon server. It is used for building Stellar apps either on Node.js or in the browser.
Js-Stellar-Base (JavaScript: 2 Open Issues): the lowest-level stellar helper library. It consists of classes to read, write, hash, and sign the xdr structures that are used in stellar-core. This is an implementation in JavaScript that can be used on either Node.js or web browsers.
Go MonoRepo (Go: 12 Open Issues): the home for all of the public go code produced by SDF. In addition to various tools and services, this repository is the SDK from which you may develop your own applications that integrate with the stellar network.
Laboratory (JavaScript: 2 Open Issues): a suite of tools to help you learn about exploring the Stellar network.
Vanity Address Generator (Rust: 3 Open Issues): a simple CLI tool to generate Stellar vanity addresses.

Nothing too crazy this week, everyone seems to have recovered from Meridian and is heads down again! Though I wanted to quickly highlight that Stellar Core has a new template for opening issues, see the changes here.

Horizon got a small update with the release of Horizon v0.22.2 that fixes a bug in accounts for the signer ingestion processor (although there’s a new version of Horizon slated for release later today).

👉Important note for Javascript SDK users: There have been two releases over the past week that you should know about, v3.2.0 & v3.3.0. These releases include a few deprecations, the big one being to stop using fee_paid in favor of max_fee and fee_charged.Read the full release notes for each release to get up to speed.

The Java SDK also had a big release (0.11.0) that includes a number of fixes and updates including added support for querying the new “strict-send” path finding endpoint.