Debugging Tips and Code Walkthrough

The DeSo blockchain is written in the Go programming language for high performance, and its code is 100% open-source, with the core and backend repos being the most important for understanding the node architecture and transaction construction respectively. The core repo represents all of the most critical code for processing transactions, while the backend repo mostly consists of REST endpoints that you can call to construct and submit transactions. If you’re curious about them, it is useful to load both repos into your IDE to explore them (we recommend VSCode or Goland; our team uses both). This being said, even though the DeSo blockchain is written in Go, you don’t have to know Go in order to construct and submit transactions! In this section, we show you how use a simple Python library to construct, sign, and submit all of the basic order management transactions you’ll need in order to write a trading bot.

The Openfund client constructs, signs, and submits the exact same transactions you’ll be working with in this tutorial (mainnet client, testnet client). This means that, if you’re ever unsure of how to do something, you can simply open up the Openfund trade page, open up the inspector, go to the network tab, and look at how Openfund is constructing and submitting the transaction (lookup a tutorial on how to use the web inspector to do this if you’re not familiar with this kind of thing). The only thing you will not be able to get from this process is the signing of the transaction, which we’ll cover in this tutorial, and which the Python library already implements for you. In addition to using Openfund to inspect things, you can also use the reference DeSo node (mainnet node, testnet node), which supports an even larger set of transactions, including making on-chain posts, following users on-chain, and much more. When Focus launches, you’ll have even more transaction types to explore there as well (focus mainnet, focus testnet). Often, when the core team adds new transaction types, they are tested on the reference DeSo nodes first, and so those are often the most “complete” places to see how transactions work. For the purposes of this tutorial, you can see how tokens are minted, burned, and sent on the “DAO” tab of the reference client, for example. For all trading transactions, though, Openfund is the best place to inspect them.

In addition, if you want to be more “hard-core,” you can read the DeSo node code itself to see how the transaction you’re trying to construct actually gets processed under-the-hood. All endpoints supported by the reference backend have a variable of the form RoutePath*, such as RoutePathUpdateProfile. If you look for usages, you will find them link dot the RoutePath with a format like this. This allows you to trace what an endpoint is doing (useful if you get a weird error). The DeSo open-source node code also provides Go functions responsible for constructing transactions, all of which follow the general naming scheme Create*Txn, such as CreateUpdateProfileTxn, and you will generally see one of these functions if you trace a RoutePath for a txn construction endpoint. Every transaction type supported by the DeSo blockchain implements a _connect function, such as _connectUpdateProfile, which is what is called when a node on the network actually processes your particular transaction. To see all of the transaction types supported by the DeSo blockchain, you can simply search for all of the _connect functions in the core repo, and then find the Create function that calls it to see how it’s constructed as well (which could be in the backend repo). While this isn’t strictly necessary information, it can be useful if you are unsure why your transaction is being rejected by the network, or if you want to see what parameters you can provide to a particular transaction type. The best way to debug is to find the _connect* function that you’re trying to trigger, and then trace it up to the function that actually constructs the transaction to see what it’s doing. In addition, if you ever get an error, you can always find it in the core+backend repo if you have them loaded in your IDE. So, to summarize:

• To see all the possible endpoints you can hit to construct transactions or get data, look for RoutePath* in the core+backend repos.

  • Find the function that gets called and trace it to see how a transaction is constructed or how data is returned.

• To see all the txn types a node can process, look for all the _connect functions in core and read through them, or find the one for your particular transaction type.

• Create*Txn functions are responsible for constructing transactions, and are typically called in txn construction endpoints. You will likely trace through them if you get a weird error.

The transactions we’ll be most concerned with for trading are as follows (for legacy reasons, DeSo Tokens are referred to in the code as “DAO Coins”:

• _connectDaoCoin

  • Used to mint and burn your token, or to change transfer restrictions

• _connectDaoCoinLimitOrder

  • Used to create market and limit orders, and to cancel orders

• _connectDaoCoinTransfer

  • Used to transfer your token to other accounts

• We won’t cover them here, but you may also be interested in the following functions, which allow you to add yield to your coin:

  • _connectCoinLockup

  • _connectCoinLockupTransfer

  • _connectUpdateCoinLockupParams

If you want, you can trace how the above functions are called all the way to the RoutePath, which will then tell you how to actually trigger them with a simple HTTP request. But it’s easier to instead inspect http requests on an existing app, like Openfund, and work “top-down” from the RoutePath, so that’s what we generally recommend. We just want to give you both options so you have the maximum ability to debug.

Whenever you’re constructing a transaction, as the next section will show you how to do, you may get a really long and hard to read error message. The key to deciphering these is to go all the way to the end and look for the RuleError that you got. For example, frequently you will have RuleErrorInsufficientBalance if you have no DESO or something like that. The RuleError should always tell you what’s going on, and be self-explanatory. But if it’s not, then you can go into the code as mentioned above and trace what’s going on. Thus is the benefit of 100% open-source software!