This guide outlines the role of service providers within the OKTC blockchain ecosystem, entities that offer end-user services involving interactions, particularly with tokens. It is designed for technical builders seeking to understand the required infrastructure and processes for seamless integration.
A service provider acts as a trusted intermediary for all end-users interacting with the OKTC blockchain. This document focuses on the core architectural components and the technical workflow for transaction handling.
Core Architectural Components
Three primary elements form the backbone of a service provider's technical setup on OKTC.
- Full-nodes: These are essential for direct interaction with the blockchain network. They maintain a complete copy of the ledger and validate transactions.
- Rest Server: This component acts as a crucial relayer, processing and forwarding HTTP calls from your applications to the blockchain network.
- Rest API: This defines the available endpoints that the Rest Server exposes, specifying how your services can programmatically interact with a full-node.
Setting Up and Running a Full-Node
To begin interacting with the OKTC network, you must first establish your own node. The following steps provide a general overview for getting a full-node operational.
Installation and Initial Configuration
The process for running and interacting with a full-node on the OKTC network is straightforward. For other SDK-based blockchains, the procedure is often very similar.
First, you will need to install the requisite node software. Following a successful installation, you can proceed to start and synchronize a full-node connected to the mainnet.
👉 Get detailed setup instructions for your node
Interacting via the Rest API
The REST API documentation is your comprehensive reference for all available endpoints to communicate with your full node. It provides detailed information on how to structure requests and interpret responses.
A key feature for developer flexibility is the API's support for generating unsigned transactions. Separate endpoints then allow you to sign these transactions using your own preferred mechanism and subsequently broadcast them to the network. This design gives service providers greater control over their security and signing processes.
Understanding OKTC SDK Transaction Signing
The process of signing transactions using the OKTC SDK is designed to be logical and secure. Every transaction within the OKTC ecosystem has a canonical JSON representation, which is the standardized format used for signing.
Key Considerations for Signers
Several critical pieces of information must be accurately supplied by the signer to create a valid transaction:
- Chain ID: The unique identifier of the blockchain network.
- Account Number: A specific identifier for the user's account.
- Sequence Number: A number that prevents transaction replays; it must increment with each new transaction from the same account.
The transaction's fee, msgs (messages containing the transaction details), and memo fields are typically supplied by the transaction composer interface. It is vital to query the correct account_number and sequence values directly from the blockchain or a reliably cached source, as errors here are a common cause of invalid signature failures.
Pre-Signing Formatting and Signature Encoding
Before the signing operation occurs, the JSON output is prepared by lexicographically sorting all keys and removing any extraneous white space. This ensures a consistent data structure for signing.
The signature itself is a 64-byte concatenation of the ECDSA signature components (r || s). To prevent malleability, the 's' value must be lexicographically less than its inverse. This approach is similar to Ethereum's standard but does not include an extra byte for public key recovery, as the Tendermint consensus mechanism assumes the public key is always provided separately.
Once signatures are correctly generated and inserted into the transaction JSON, the finalized and signed transaction can be broadcast to the network for processing.
Frequently Asked Questions
What exactly is a service provider in the OKTC context?
A service provider is an entity that builds and offers services for end-users, facilitating their interaction with the OKTC blockchain. They operate trusted infrastructure, like full-nodes and REST servers, to handle tasks primarily involving tokens and transactions.
What is the main difference between a full-node and a REST server?
A full-node is the fundamental software that connects to the blockchain network, maintains the ledger, and validates data. The REST server is a separate layer that sits on top, accepting HTTP requests from applications and relaying them to the full-node in a format it understands.
Why is the sequence number so important in transaction signing?
The sequence number is a critical security feature. It acts as a nonce, ensuring that each transaction from an account is unique and preventing malicious actors from rebroadcasting or replaying the same transaction multiple times.
Can I use my own custom method for signing transactions?
Yes, the architecture provides flexibility. The REST API allows you to generate unsigned transactions. You can then sign these transactions using your own secure signing mechanism or hardware wallet before using another endpoint to broadcast the signed transaction.
Where can I find the complete list of API endpoints?
The complete and authoritative documentation for all available REST API endpoints is maintained by the OKTC community. This documentation details request formats, parameters, and response models for every interaction.
What is the most common mistake when first integrating transaction signing?
The most frequent issues arise from incorrect chain ID, account number, or sequence number values. Always ensure these values are fetched directly from the blockchain or a highly reliable and updated source to avoid invalid signature errors.