Casper SDK Landscape Part 1

Published in

Casper Association R & D

9 min readFeb 14, 2023

Introduction

Welcome to the Casper R&D blog. This is the first of a series of articles reviewing the Casper SDK landscape. Healthy blockchain ecosystems require a set of high quality SDK’s implemented in the programming languages demanded by the community of builders. The Casper Association plays an important role in coordinating work across the Casper SDK landscape, the coordination mechanisms are as follows:

Establishing a uniform SDK development agenda.
Prioritizing SDK funding in response to community feedback.
Overseeing communication flows between core engineering team and SDK development teams.
Mandating an integrated SDK CI/CD infrastructure.
Issuing SDK certification in respect of SDK implementation quality and depth.

This article focuses upon establishing a uniform SDK development agenda. The article structure is as follows:

High level review of the Casper node API surface.
High-level assessment of typical SDK functionality.
Elaboration of the function set that an SDK is expected to expose.
Discussion in respect of SDK standardization.

Note that our discussion will be agnostic in respect of the programming language that an SDK may be implemented in, such considerations will appear in follow up articles.

Node API Surface

A Casper node exposes a set of endpoints distributed over an API surface that supports 3 communications protocols:

1. JSON-RPC: A light weight remote procedure call protocol. This is the primary protocol for either dispatching deploys or issuing queries.

2. REST: An API architectural style that uses HTTP requests to access and use data. Over this protocol one can issue operational data queries.

3. Server Sent Events (SSE): A server push technology enabling a client to receive automatic updates from a server via an HTTP connection.

A node operator is at liberty to establish custom access control policies in respect of the set of exposed communication protocols, ports and endpoints. Furthermore a node operator has the latitude to set parameters (e.g. max. queries per second) that directly impact node API behavior.

A key takeaway here is that SDK end users should not make out of the box trust assumptions in respect of the behavior and API surface associated with any particular node. It is thus incumbent upon an SDK end user to clarify in advance the policies put in place by the operators of the nodes that they intend to interact with.

Endpoint discovery is possible by inspecting endpoint schema documents declared in JSON schema format. These documents declare sets of served endpoints , i.e. address, input arguments, return types … etc. By inspecting such documents an SDK development team can quickly understand the low level messaging mechanics of interacting with a node.

SDK Function Groups

In essence an SDK is simply a library that exposes a set of functions. The function set may be grouped as follows:

G01:Node & Chain Queries
G02:Node Event Monitoring
G03:Deploy Instantiation
G04:Deploy Dispatch
G05:Data Serialization
G06:Cryptography
G07:Miscellaneous

G01: Node & Chain Queries

Any serious user of a blockchain system, e.g. a bank, will be continuously tracking the state of the chain. This necessitates issuing a wide array of queries in respect of accounts, blocks, deploys, global state, proofs, auction state … etc.

Node operators may also expose query endpoints related to node operations such as metrics, peers, status … etc. This source of information is primarily used to monitor the health of the node and by extension the wider network.

Taken in combination, i.e. tracking chain state or node state, the query space is large. Generally speaking it is in a node operator’s best interests to route query servicing to auxiliary API’s exposed by dedicated chain/node indexation services. However this does of course incur additional trust assumptions in respect of the operational integrity of the indexation service provider(s).

G02: Node Event Monitoring

Binding to a node’s event stream over an SSE channel permits an end user to receive real time notifications in push mode. Broadly speaking such notifications pertain to block, deploy & consensus events.

A node’s event stream emits voluminous amounts of data, thus an SDK may support client-side event filtering so as to filter out unwanted noise. An example filter might be “filter events by those emitted by a distinct set of smart contracts”.

Real time event monitoring is essential for DApp operators who have deployed smart contracts onto the platform. Of particular note here is monitoring smart contract level events, the mechanics of which require direct binding to, filtering over and parsing the SSE channel.

G03: Deploy Instantiation

Deploy instantiation revolves around 3 elements: session logic, payment logic & approvals. Session and payment logic represent inputs for interpretation by the node’s execution engine. Approvals are a set of signatures authorizing deploy processing.

A deploy either missing or incorrectly formatting any one of these 3 elements will be automatically rejected by a node. Therefore an SDK should expose a set of helper functions to abstract away the low level complexities of the instantiation process.

Session logic represents the business logic to be executed on-chain. There are 3 variants of session logic:

A natively supported operation such as a CSPR transfer.
An on-chain smart contract (WASM) installation or invocation.
On the fly WASM payload invocation.

Payment logic represents the mechanism via which the platform will collect transaction fees associated with execution of the session logic. The payment may be processed natively (simple fee), delegated to a smart contract endpoint, or on the fly via WASM.

Deploy approvals are a set of signatures issued by a set of private keys associated with the account under which the deploy is to be dispatched and processed on-chain. The Casper platform supports a form of account abstraction via which deploy authorization can be delegated to a weighted set of ≥ 1 associated keys. Useful in multi-signature scenarios.

G04: Deploy Dispatch

Only correctly instantiated deploys can be dispatched to a node for processing. The dispatch target can be any node that has joined the network, i.e. it does not have to be a validator node.

An SDK should provide support for 2 types of dispatch: normal & speculative.

Normal dispatch results in a deploy being gossiped across the network and placed upon a local deploy queue for subsequent processing by a validator node.
Speculative dispatch results in the deploy being executed in a sand-boxed, side-effect free environment upon the target node. This is highly useful for estimating deploy processing gas fees.

An SDK user should implement a fault tolerant deploy dispatch mechanism the elements of which may include:

Specifying an appropriate deploy time to live.
Leveraging a message broker with retry capabilities.
Leveraging a whitelisted set of target dispatch nodes.
Thinking through the consequences of dispatch failure and implementing appropriate fallback logic.

Even if deploy dispatch is successful, under no circumstances should an SDK user blindly assume that a deploy will be successfully processed. Always monitor the appropriate SSE channel(s) so as to reach certitude that the system’s finality mechanism has been successfully applied to a block in which the dispatched deploy has been included.

This requires tallying the consensus weight of the validator accounts associated with the set of reported block finality signatures against the total consensus weight of the validator accounts reported in the currently active validator set.

Deploy dispatch and subsequent finality monitoring is a non-trivial exercise in a production setting. Specialist service providers may be of use in this context but again note that this incurs an added trust overhead.

G05: Data Serialization

All data pushed to a node for processing must strictly conform to the Casper CL Type serialization standard. Conformance failure results in validation errors and hence deploy rejection.

Whilst the over the wire deploy serialization format is JSON, the underlying data serialization format is binary. The binary format conforms to the CL Type system.

As a result the rules for correctly encoding binary data to be interpreted by a node are extremely precise. A single bit encoding error results in the deploy failing validation checks and hence being rejected at the point of dispatch.

Correct implementation of the binary data serializer is probably the trickiest task awaiting an SDK development team. Fortunately by now the binary serialization standard is fairly well formalized and of course multiple implementations exist in the wild from which to learn.

G06: Cryptography

In order for an SDK to successfully dispatch a deploy to a node for execution it will have to correctly construct deploys. To do this an SDK must support a set of 1st order cryptographic algorithms plus a set of associated 2nd order derivation functions. The 2nd order functions leverage the 1st order algorithms in order to perform tasks such as key generation, account derivation, deploy hashing, deploy signatures and checksum calculations.

The 1st order cryptographic algorithms of interest are blake2b (hashing), secp256k1 (signature scheme) & ed25519 (signature scheme). Each of these algorithms will find high quality implementations in all SDK programming bindings. Typically an SDK simply has to create a few helper functions to sink calls to the specialist libraries.

Failure to correctly implement the set of 2nd order functions will result in endless errors when trying to dispatch a deploy to a node for processing. For example, in order to derive the chain address of an account, a higher order function, get-account-hash, must be correctly implemented by the SDK team. If this function is incorrectly implemented then transfers (for example) will fail.

G07: Miscellaneous

Finally SDK’s may expose a set of miscellaneous functions for performing tasks such as loading WASM files, loading cryptographic keys, validating a deploy. Such functions simplify an SDK user’s life in various ways.

SDK Function Sets

Now that the set of function groups have been elaborated, let’s proceed to consider the function sets associated with each group. Appended to this article is a non-exhaustive list of grouped function sets. The list has been compiled by reviewing the SDK implementation landscape.

It is worth noting that we could proceed to further classify each function along various dimensions such as:

requirement -> MANDATORY | OPTIONAL
complexity -> HIGH | MEDIUM | LOW
order -> FIRST | SECOND
dependencies -> NONE | SET
binds to node -> TRUE | FALSE

In a heterogeneous SDK landscape there may naturally be a degree of variance in respect of function names, signatures, support … etc. However by arriving at a clearly defined set of supported functions, classified accordingly, we lay the foundations of a standardization process empowering upstream activities:

SDK Certification — each SDK can be certified according to depth of implementation. Of course certification would also have to take into consideration other factors such as ease of use and depth of documentation.
Cross SDK Test Platform — as the Casper 2.X series rolls out, it will be important to identify regressions as quick as possible, a test platform is essential in this respect.

Summary

This is the first article in a series reviewing the Casper SDK landscape. Following an introduction, we set the scene by describing the Casper node’s available API surface. We then elaborated upon the various functional groups of concern to SDK authors. Finally we touched upon the full function set to be implemented, and how standardization in this context leads to upstream benefits such as certification & testing.

In follow up articles we will continue to review the SDK landscape and dig deeper into the various implementations out in the wild. We will talk about the teams involved and the challenges that they have or are facing.

Appendix: Grouped Function Set