ARK’s Platform SDK — Modernization of Blockchain Network Interactions

Platform SDK makes it simple to interact with different networks. Signing, verifying, broadcasting transactions and obtaining networks specific data has been standardized to make it a breeze to integrate different blockchain networks in a matter of minutes depending on your needs.

Platform SDK is open-source and available at https://github.com/arkecosystem/platform-sdk

If you have missed the introduction post to Platform SDK give it a read here.In this blog post, we’ll go a bit more into technical detail in what the biggest challenges were when building Platform SDK and the solutions to those problems.

#The Problem

While we tried to come up with a standardized interface for the implementation and interactions with all kinds of different blockchain networks we ran into 3 major issues due to how those different coins worked.

#Identifying Wallets

The way you publicly identify wallets can differ between coins. Some coins have the concept of addresses which means your wallets will have an address, public key and private key. On the other hand, you have coins that only have a public key and private key.

This meant for some coins, people are used to using their address to interact with other people, while for another group of people it is normal to use their public key. This meant we had to come up with a standardized interface for our implementations that would provide us with the primary identifier of a wallet without exposing if it is an address or public key.

#Methodology To Sign Transactions

The same way identifying wallets differs between coins the method with which data is signed also differs. With BTC, ETH or XLM, for example, it is common to use your private key to sign transactions and messages instead of using a mnemonics while with ARK we expect the user to provide their mnemonics and even our SDKs are built in a way to encourage people to use their mnemonics.

This meant that we had to come up with a standardized interface for our implementations that would allow us to sign transactions and messages with all kinds of different user inputs like mnemonics, private keys or even WIFs.

#Required Data To Sign Transactions

The last and biggest difference when it comes to differences between coins is the so-called unspent transaction output (UTXO) which is necessary for coins like BTC. The UTXO will be consumed when you create a new transaction and is required to be requested from the network before you can build and sign a transaction. This is quite a bit more complicated than for example ARK where you just enter an amount, sign the transaction and broadcast which will result in the transaction either being accepted or rejected because you have an insufficient balance.

This meant that we had to come up with a normalized way for our implementations that would allow us to perform all of those underlying network calls without exposing them to the consumer.

#The Solution

Now that we’ve identified the biggest problem areas that needed to be standardized we can look at the actual solutions we came up with and why we chose the solutions we ended up implementing.

#Identifying Wallets

As previously mentioned we needed a way to uniquely identify wallets in order to know who we are interacting with. The way it works with BTC and ARK is fairly simple where you have an address, public key and private key that are based on a unique mnemonic.

In terms of implementation in our Platform SDK, it would look something like the below for BTC and ARK where we expose the address and public key through methods on a wallet instance.

Now the issue comes into play where some coins don’t have addresses but you still need a way to address a wallet for a transaction. This is a scenario where we have to basically alias the public key of a wallet to an address in terms of specifications and code which would look something like the below for something like ETH.

We have to do this in order to allow our user-facing products that will consume the SDK to not have to think about what the unique identifier of a wallet is. All they have to think about is to call the address method to get the unique identifier of a wallet and then proceed to interact with it.

#Methodology To Sign Transactions

This problem was one of the easiest to solve because we use TypeScript and can type-hint everything. This meant that we could simply define a TransactionInput implementation contract and get proper type detection in any modern editor.

The TransactionInput.sign property is an important part of the above code because the implementation of the transaction signing method for each coin will use this object to determine how a transaction should be signed.

1. The sign.mnemonic property will be used to sign a transaction with a single passphrase.
2. The sign.mnemonics property will be used to sign a transaction with multiple passphrases for things like multi-signatures.
3. The sign.secondMnemonic property will be used to sign a transaction in combination with another passphrase.
4. The sign.wif property will be used to sign a transaction with a WIF.
5. The sign.secondWif property will be used to sign a transaction in combination with another WIF.
6. The sign.privateKey property will be used to sign a transaction with a private key.

All of these different signing methods are methods that will eventually be implemented in our user-facing products and provide a seamless UX between multiple coins and networks.

#Required Data To Sign Transactions

This was by far the trickiest and most problematic error to solve because of how big the difference between some coins are. As before mentioned some coins like BTC have the concept of unspent transaction output (UTXO) while other coins require a nonce and yet again others don’t require any of these and could sign a transaction completely offline without any network calls.

The standardizing of the implementation contract was the easiest part, but those methods can be quite error-prone with different coins because of how they work. With BTC, for example, you could be unable to broadcast a transaction because a node reports false UTXO for your wallet which will make it impossible to build and sign a transaction or multiple nodes could refuse connection while other coins will work perfectly fine because they don’t rely on any network information which makes it possible to sign them completely offline.

Since these issues can’t really be handled in any other way than letting the user know that something went wrong, we will direct any errors directly to the UI. Any issue that occurs during the building and signing of a transaction will be displayed in the UI with a clear explanation and the user can manually retry to reach the network again.

These error messages can differ per coin and network because of different concepts like fees, gas and gas limits are implemented and behave but we will try our best to show as many details as possible about the error that occurred.

#The Integration

Integrating and interacting with the Platform SDK is fairly simple due to the abstractions we provide that help with instantiating the concrete implementations for a specific coin and network.

The Platform SDK is currently being integrated into our own user-facing applications which means there can be bugs, breaking changes, or unwanted behaviors until the full integration is finished. Proceed with caution.

In order to interact with the Platform SDK, you will need to create an environment. An Environment is simply an instance of what gives you access to all underlying integrations like profiles, wallets and the way wallets interact with their underlying coin. Creating a new environment is fairly straightforward.

Once the environment has been created you will need to create a profile in order to create wallets. Again, this is fairly straightforward as most other things in the Platform SDK.

Finally, you will need to either create or import a wallet to your profile. In this example, we will import a wallet from an existing mnemonic for the ARK Development Network.

For more detailed examples and a list of all available methods, you should check out our examples and documentation which you can find in the docs directory of every package .

As previously mentioned: Please keep in mind that the Platform SDK is primarily designed around how we plan to consume it and meet our needs. This means that pull requests, major changes, or feature requests will generally be closed and you should instead opt to use a fork of your own.

#How Can I Help?

There is plenty of work still to be done and anyone can contribute! You can help us test by integrating and interacting with different networks, find and report bugs, resolve bugs, or simply give us feedback/criticism that will help us improve the Platform SDK!

• Issues, feedback, criticism:
• Improvements or bug fixes: