Computer implemented method and system

Abstract

A computer-implemented method is provided. A first step of the method comprises obtaining a transaction related data point. A second step comprises extracting features of the transaction related data point to determine a feature vector based on the transaction related data point. A third step comprises mapping the feature vector to an embedding space using an encoder model to determine an embedding vector as an output of the encoder model, wherein the encoder model is trained to map related transaction related data points in close proximity to each other within the embedding space. A fourth step comprises applying a cluster model to the embedding vector, wherein the cluster model is trained to identify and form clusters of transaction related data points across the embedding space, the clusters comprising a plurality of buckets. A final step comprises assigning the transaction related data point to a one or more buckets based on an output of the cluster model, each bucket having an associated bucket ID. A method of training an encoder model is also provided.

Description

[0001] COMPUTER IMPLEMENTED METHOD AND SYSTEM

[0002] FIELD

[0003] The present disclosure relates to a method of distributing transactions for processing in a scalable and efficient way. A method of training an encoder model for distributing the transactions in an embedding space is also provided.

[0004] BACKGROUND

[0005] The advent of blockchain technologies has fundamentally transformed transaction management by introducing decentralised, secure, and transparent systems for value transfer. Unlike traditional centralised systems, blockchain eliminates the need for intermediaries, thereby increasing transparency and robustness against single points of failure. However, these benefits come with significant scalability challenges. As the number of users and transactions increases, ensuring the integrity and security of the ledger becomes more complex. The system must handle a growing volume of transactions without compromising on performance or security, which is crucial for broader adoption. In Unspent Transaction Output (UTXO)-based blockchains like Bitcoin, each transaction (except coinbase transactions) consumes existing UTXOs and creates new ones. This UTXO model is essential for maintaining the integrity of the blockchain ledger but poses unique challenges for scalability and efficiency.

[0006] Recent advances in Machine Learning (ML) have opened new avenues for optimising processes in a variety of fields, and blockchain technology is no exception. ML techniques, which leverage powerful algorithms and computational models, can analyse and learn from large datasets to make intelligent decisions and predictions. This capability is particularly relevant for blockchain systems, where optimising transaction management processes can significantly enhance performance.

[0007] Blockchain technologies offer decentralized, secure, and transparent transaction management. However, scalability remains a significant challenge due to the growing volume of transactions.

[0008] Traditional methods of transaction validation face limitations with increasing transaction volumes. Sharding and parallelizing transaction validation can help but also introduces complexities, such as high communication overhead.

[0009] SUMMARY

[0010] A computer-implemented method is provided. A first step of the method comprises obtaining a transaction related data point. A second step comprises extracting features of the transaction related data point to determine a feature vector based on the transaction related data point. A third step comprises mapping the feature vector to an embedding space using an encoder model to determine an embedding vector as an output of the encoder model, wherein the encoder model is trained to map related transaction related data points in close proximity to each other within the embedding space. A fourth step comprises applying a cluster model to the embedding vector, wherein the cluster model is trained to identify and form clusters of transaction related data points across the embedding space, the clusters comprising a plurality of buckets. A final step comprises assigning the transaction related data point to a one or more buckets based on an output of the cluster model, each bucket having an associated bucket ID. A method of training an encoder model is also provided.

[0011] According to a second aspect there is provided a method of training an encoder model for mapping related transaction related data points in close proximity to each other within an embedding space. The method comprises obtaining as an input for the encoder model: a feature vector %“ representing an anchor transaction related data point;a feature vector xvtrepresenting a positive transaction related data point which is related to the anchor transaction related data point; and a feature vector representing a negative transaction related data point which is unrelated to the anchor transaction related data point. The method comprises configuring the encoder model to map the feature vectors*" , xvt, * to an embedding space using the encoder model to output embedding vectors h , hvt, h for each of the anchor transaction related data point, the positive transaction related data point, and the negative transaction related data point respectively, wherein an embedding vector is an embedding which describes a location of the transaction related data point in the embedding space. The method of training includes using a triplet loss approach to: minimise a distance between mbeddings of the anchor transaction related data point h „ and the positive transaction related data point fi’’; and maximise a distance between embeddings of the anchor transaction related data point h and the negative transaction related data point Zi .

[0012] Preferably the encoder of the first aspect is trained according to the method of the second aspect. Preferably there is provided a processor configured to execute computer-executable instructions to generate the trained encoder model described herein.

[0013] According to a third aspect, there is provided a network node. The network node includes a memory, the memory comprising one or more memory units, and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform a method described herein.

[0014] According to a fourth aspect, there is provided a computer readable storage medium. The computer readable storage medium includes computer-executable instructions which, when executed, configure a processor to perform a method described herein.

[0015] BRIEF DESCRIPTION OF THE DRAWINGS

[0016] To assist understanding of embodiments of the present disclosure and to show how such embodiments may be put into effect, reference is made, by way of example only, to the accompanying drawings in which:

[0017] Figure 1 illustrates a flowchart of a method according to an embodiment of the present disclosure;

[0018] Figure 2 illustrates a block diagram of the method of Figure 1 ;

[0019] Figure 3 illustrates a schematic diagram of a method used to train the encoder model;

[0020] Figure 4 illustrates an example of a structure of the encoder model;

[0021] Figure 5 illustrates combinations of triplets of embedding vectors comprising a hard case, a semi-hard case and an easy case.

[0022] DETAILED DESCRIPTION OF EMBODIMENTS

[0023] While the term "Bitcoin" may be referred to as a useful application of the technology described in the present disclosure, for the purpose of convenience and illustration, Bitcoin is just one of many applications to which the technology described in the present disclosure may be applied. However, it should be noted that the invention is not limited to use with the Bitcoin blockchain; alternative blockchain implementations and protocols, including non-commercial applications, also fall within the scope of the present invention.

[0024] As used herein, a "digital asset" is a unit of a resource managed by a blockchain. Although the digital asset may, in some embodiments, be used as cryptocurrency, it is contemplated that the digital asset, in embodiments, is additionally or alternatively usable in other contexts. Note that the invention, while applicable to the control of digital assets, is technical in nature and can be used in other contexts that utilise blockchain data structures without necessarily involving the transfer of digital assets. For example, the nodes may take action involving a digital asset (such as digital currency, tokens or other stake or value). In various examples, the resources may be a cryptographic key, code, quantity of cryptocurrency, unspent transaction output. For example, it is to be understood that while transactions may transfer Bitcoins, users may instead exchange other resources using the methods and systems described herein, such as information, contracts, and tokens.

[0025] In order for a transaction to be written to the blockchain, it must be "validated". Some network nodes act as miners and perform work to ensure that each transaction is valid, with invalid transactions rejected from the network, i.e. added to the public ledger of past transactions.

[0026] A "blockchain transaction" refers to an input message encoding a structured collection of field values comprising data and a set of conditions, where fulfilment of the set of conditions is prerequisite for the set of fields to be written to a blockchain data structure. For example, each transaction is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output.

[0027] As the blockchain network scales and the number of transactions increases, traditional methods of IITXO assignment and transaction validation often encounter limitations, such as an increasing IIXTO set size and a massive number of transactions per second to be validated. Sharding the IITXO set parallelises transaction validation, however, when a new transaction is received, it is crucial to identify where the UTXOs being spent are located (i.e., in which IITXO shard). Failing to do this could lead to high communication overhead and slow transaction processing times.

[0028] Experimental approaches address scalability by sharding the IITXO set and incoming transactions across a distributed system of validators based on transaction hashes. This deterministic method often results in a pseudo-random distribution, leading to incoming transactions being assigned to microservices without the necessary parent UTXOs required for validating incoming transactions, wherein a “microservice” is an independent transaction validator within a mining node connected to the blockchain network. Inter-microservice communication is required to fetch the missing parent UTXOs, raising communication overhead and consuming resources that could be used for transaction processing. In this context, optimizing intra-node UTXO allocation to reduce communication overhead and streamline validation remains a key challenge in scaling UTXO-based blockchains like Bitcoin.

[0029] Furthermore, while blockchain transactions are described herein, the present disclosure is not to be considered as being limited to blockchain transactions. The present disclosure applies machine learning (ML) techniques to improve the distribution of transaction related data points (where transactions comprising UTXOs are provided as an example throughout) and optimise transaction validation processes to address these challenges more effectively. ML-driven approaches have potential to strategically allocate UTXOs and manage transactions, reducing the need for inter-node communication and enhancing overall network performance. ML provides a compelling solution for improving the scalability and efficiency of UTXO-based blockchains.

[0030] The present disclosure provides a dual-model architecture which combines self-supervised and unsupervised learning to perform spending-based clustering on transaction outpoints. Transactions are mapped into a structured embedding space to group related transactions closely, which are then clustered and assigned to validation buckets. Self-supervised learning is used in training the encoder model for mapping the transactions. This approach embeds spending relationships directly into the model's weights during training, eliminating the need for real-time parent transaction lookups during inference.

[0031] Initially, feature vectors x e Rdrepresenting outpoints are fed into an encoder model x £ Rdwhich learns to project these vectors into a structured embedding space £ c ]&fe. The present disclosure maps parent and child transactions into proximity within the embedding space, even if they are far apart in the original feature space. This alignment ensures that transactions sharing a common lineage are grouped closely in the embedding space. Once a meaningful and well-organised embedding space £ is achieved, a cluster model g02: £ -> { , C2, ... , £„} is applied to identify clusters C of these transaction outpoints. These clusters then form buckets, which are distributed across validation microservices within one node on the network. For new incoming transactions that node receives, the outpoint feature vectors xneware mapped into the embedding space £ and assigned a bucket ID based on their cluster q. The set of bucket IDs {(" } associated with a transaction determines the specific microservices to which the transaction will be routed for validation.

[0032] The present disclosure learns spending relationships while circumventing the need for lookups during inference, thereby enhancing the efficiency and scalability of transaction validation. To achieve this, the spending relationships from historical data are embedded directly into the model's learnt weights during the training phase. This contrasts with current spending relationships being required to form part of the model inputs, as is the case with graph-based models. By leveraging a self-supervised learning technique, the model is trained using a triplet loss function [1], [2] with online hard negative triplet mining. Positive pairs are derived from parent-child transactions, while negative pairs are derived from unrelated transactions. This training approach ensures that the model captures the transactional lineage and spending patterns effectively.

[0033] At inference time, the encoder model described herein requires only the transaction features that are immediately available when a new incoming transaction is received. By embedding the spending relationships within the model parameters, a need for lookups of the parent transaction during transaction validation is eliminated, thereby reducing communication overhead. This approach not only preserves the integrity of the transactional lineage but also significantly enhances the overall performance and scalability of UTXO-based blockchain networks.

[0034] A solution for smart sharding the IITXO set into buckets and routing these shards and incoming transactions to appropriate microservices within a mining node using an ML model trained on spending relationships is provided. This approach enhances scalability by eliminating the need for inter-node communication to fetch parent UTXOs, as the model accurately routes incoming transactions to the buckets containing their parent UTXOs. Advantages of the present disclosure lie in the embedding model and encompass three key aspects:

[0035] • Elimination of Communication with Blockchain During Model Inference: Unlike prior art methods that use graph-based models that require fetching parent transaction data, the present disclosure operates solely with the information immediately available when an incoming transaction is received at a node.

[0036] • Creation of Transaction Outpoint Embeddings: The present disclosure ensures that embeddings of parent-child transactions or transaction outpoints are similar under a chosen metric (e.g., Euclidean distance). This allows us to use learned weights, capturing spending relationships during training, to embed new transaction outpoints consistently with their parents. A clustering model then identifies clusters from these learnt embeddings and assigns bucket IDs, which determine transaction routing to microservices.

[0037] • Training Approach with Triplet Loss: The training approach described herein uses a triplet loss function with online hard negative triplet mining on triplets of transactions or transaction outpoints, dynamically selecting hard and semi-hard negatives within the embedding space as it evolves with training. This method ensures the model effectively captures spending relationships during training.

[0038] Figure 1 illustrates a flowchart of a method 100 according to an embodiment of the present disclosure. Figure 2 illustrates a block diagram of the method 100 of Figure 1 comprising the steps 105 to 120. Figure 1 shows a method of sharding / tagging a new transaction once it arrives at a receiving node. This is provided by way of example. A person skilled in the art will appreciate that the steps could similarly apply to transaction related data more generally, including transactions comprising data relating to a smart contract. For example, a IITXO from the IITXO set (presuming the IITXO data has the appropriate transaction global features) could also be used. Additionally or alternatively, the steps could operate on a subsection of a complete transaction. Additionally or alternatively, a transaction (or subset thereof) may be associated with a specific smart contract. Similarly, a smart contract and / or transactions associated with a smart contract may advantageously clustered in close proximity to one another to improve smart contract execution.

[0039] According to a first step 105, an incoming transaction Tx is received, the transaction comprising at least one output. The transaction is received at a node of the blockchain network, such as a mining node or a validating node. In one embodiment, the transaction is a IITXO transaction. In some embodiments, the incoming transaction has more than one output.

[0040] According to a second step 110 features of the incoming transaction are extracted to determine a feature vector of the incoming transaction. The features to be extracted in some examples include global, local and positional features of the transaction which are extracted to determine a three-part feature vector. The three-part feature vector comprises a concatenation of the global, local and positional features. Global features extracted from the transaction relate to a descriptor of the transaction. Local features relate to outpoint specific attributes of the transaction, for example relating to a locking script of an output within a transaction. Extracting the local set of features comprises encoding a vector representation, for example a binary vector representation, capturing the presence or absence of determined OP codes within the locking script. This extraction of local fields from the locking script is referred to as a “Bag of OP codes”. Positional features of the transaction comprise a positional encoding vector for indicating a given outpoint position within the transaction.

[0041] If the incoming transaction has more than one output, a feature vector is determined for each output of the incoming transaction.

[0042] According to a third step 115, the feature vector determined in the second step 110 is mapped to an embedding space using an encoder model to determine an embedding vector as an output of the encoder model. The encoder model maps related transactions in close proximity to each other within the embedding space. A related transaction may refer to a parent-child relationship, for example. Related transactions may share a transaction history on the blockchain, for example. The encoder model is trained using self-supervised learning. If the incoming transaction has more than one output, an embedding vector for each output is determined from the encoder model.

[0043] According to a fourth step 120, a cluster model is applied to the embedding vector. The cluster model is trained to identify and form clusters of transactions across the embedding space, the clusters comprising a plurality of buckets. The transaction is assigned to a bucket having an associated bucket ID using the cluster model. The cluster model assigns transactions to buckets based on the mapping of the transaction in the embedding space according to the third step 115. The number of buckets is variable and may be between ten and one hundred, for example. The cluster model is trained using unsupervised learning.

[0044] If the incoming transaction has more than one output, the cluster model is applied to each embedding vector and a bucket ID for each of the transaction outputs is determined. The incoming transaction is assigned to each of the buckets for which a bucket ID is determined. This helps to ensure that when a transaction is ready for validating that a parent of the transaction will be found in the bucket which the transaction has been allocated to.

[0045] The buckets may be distributed across microservices within a single node or across multiple nodes within the blockchain network, wherein the correct assignment of incoming transactions to the appropriate bucket enables parallel validation and processing by the respective microservices or nodes.

[0046] Steps 105 to 120 are performed at a first entity, for example a first node. Optional steps 125 and 130 may in some examples be performed at a different entity to the first entity.

[0047] According to a fifth optional step 125, a parent transaction of the transaction for validating is located. In some examples, the parent transaction can be found within the same bucket that the transaction for validating has been assigned to in the fourth step 120. However, if the parent transaction is not in the bucket that the transaction for validating was assigned to, nearest neighbours of the bucket that the transaction for validating was assigned to are searched for the parent transaction. Due to the mapping of the transactions using the embedding and cluster model, if the parent transaction is not in the bucket that the transaction for validating is in, the parent transaction is likely to have been mapped to a bucket in proximity to the transaction for validating so is likely to be in a bucket that neighbours the bucket that the transaction for validating has been assigned to. According to step 130, the transaction Tx is validated.

[0048] UTXO model

[0049] According to the first step 105 of Figures 1 and 2, an incoming transaction Tx is received, the transaction illustrated in Figure 2 is a UTXO transaction comprising inputs and outputs. A transaction is the fundamental data structure of the blockchain (each block comprising one or more transactions). The following will be described by reference to an output-based or “UTXO” based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other example blockchain networks.

[0050] In a UTXO-based model, each transaction (“Tx”) comprises a data structure comprising one or more inputs, and one or more outputs. Each output may comprise an unspent transaction output (UTXO), which can be used as the source for the input of another new transaction (if the UTXO has not already been redeemed). The UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger. The UTXO may also contain the transaction ID of the transaction from which it came, amongst other information. The transaction data structure may also comprise a header, which may comprise an indicator of the size of the input field(s) and output field(s). The header may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header of the raw transaction submitted to the nodes.

[0051] The terms “preceding” and “subsequent” as used herein in the context of the sequence of transactions refer to the order of the transactions in the sequence as defined by the transaction pointers specified in the transactions (which transaction points back to which other transaction, and so forth). They could equally be replaced with “predecessor” and “successor”, or “antecedent” and “descendant”, “parent” and “child”, or such like. It does not necessarily imply an order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. Nevertheless, a subsequent transaction (the descendent transaction or “child”) which points to a preceding transaction (the antecedent transaction or “parent”) will not be validated until and unless the parent transaction is validated. A child that arrives at a blockchain node before its parent is considered an orphan. It may be discarded or buffered for a certain time to wait for the parent, depending on the node protocol and / or node behaviour.

[0052] One of the one or more outputs of a parent transaction comprises a particular UTXO. Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input of a child transaction in order for the child transaction to be validated, and therefore for the IITXO to be successfully redeemed.

[0053] The locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol. A particular example of such a language is called “Script” (capital S) which is used by the blockchain network. The locking script specifies what information is required to spend a transaction output. Locking scripts appear in the outputs of transactions. The unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. Unlocking scripts appear in the input of transactions.

[0054] Note that the script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. “OP_...” refers to a particular opcode of the Script language. As an example, OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain. E.g. the data could comprise a document which it is desired to store in the blockchain.

[0055] Feature Extraction

[0056] According to the second step 110 a feature vector of the Tx is determined. Global, local and positional features of the transaction are extracted directly from a transaction as it is received to determine a three-part feature vector. A transaction outpoint (also referred to as a transaction output) is transformed into a three-part feature vector. The features derived are summarised below in Table 1. The features in Table 1 are available from the transaction without further lookup or derivation required. The first part captures global transaction features, including input / output counts, statistical summaries of output amounts, and the encodings of the unlocking and locking scripts. The second part focuses on outpoint-specific attributes, such as the amount and the size of the locking script. The final part includes positional encodings [3] to differentiate identical outpoints. These components are concatenated to create the feature vector, serving as the input to the encoder model f9i, shown in Table 1. Since f9iefficiently buckets incoming transactions in real-time, it relies on the immediately available data when receiving an incoming transaction, and no other data such as parent related data. Of note, all of the features set out in Table 1 are immediately derivable from a received transaction (or appropriate subsection of a transaction). That is to say, no look ups are required to classify a received transaction. Table 1 illustrates features for Bitcoin transactions and outpoints. Size denotes number of elements in the feature vector.

[0057] To encode the locking script information for local, outpoint features, a “Bag of OP Codes” method is used which is an encoding method like the bag of words approach used in Natural Language Processing (NLP). In this technique, a vocabulary of OP codes is created, as illustrated for example in Table 2, which are operation codes commonly used in Bitcoin script. Each scriptPubKey, a part of the transaction output that defines the conditions required to spend the output, is then analysed. For each OP code in the vocabulary, if it appears in the scriptPubKey, the corresponding vector index position is set to 1 ; otherwise, it is set to 0. This binary vector representation captures the presence or absence of specific OP codes within the script. Additionally, an "Other" category is included for any out-of-vocabulary OP codes, ensuring comprehensive coverage of the script's operational content. Examples of Bag of OP codes encodings for common scriptPubKey scripts are shown in Table 3. This method provides a structured way to encode and compare Bitcoin scripts based on their OP code composition. This approach provides a comprehensive way to encode and compare scripts, which is important for accurate transaction validation.

[0058] Table 2 illustrates an example vocabulary for Bag of OP Codes.

[0059] Table 3 illustrates examples of Bag of OP Codes encodings. By creation of transaction outpoint embeddings achieved by feature extraction, the method ensures that embeddings of parent-child transactions or transaction outpoints are similar under a chosen metric (e.g., Euclidean distance). This allows use of learned weights, capturing spending relationships during training, to embed new transaction outpoints consistently with their parents.

[0060] Training the Encoder Model

[0061] A method of training an encoder model for mapping related transactions in close proximity to each other within an embedding space is described. Figure 3 illustrates a schematic diagram of a method used to train the encoder model. The method uses a triplet loss approach. For a triplet of transactions comprising an anchor, a positive and a negative transaction, the encoder model takes as input: a feature vector x“ 305-a representing an anchor transaction; a feature vector 305-p representing a positive transaction which is related to the anchor transaction; and a feature vector x 305-n representing a negative transaction which is unrelated to the anchor transaction.

[0062] As mentioned previously, transactions are used here for ease of explanation and are provided as an example only of transaction related data. A person skilled in the art will appreciate that similar techniques will work on subsections of transactions, transaction outputs (i.e. UTXOs), and similar.

[0063] The encoder model 310 maps the feature vectors %“ , xvt, x to an embedding space using an encoder model to output embedding vectors 315-a, 315-p, 315-n for each of the anchor transaction ha, a positive transaction hp, and the negative transaction hnrespectively. The embedding vector is an embedding which describes a location of the transaction in the embedding space.

[0064] The triplet loss approach 320 is trained to minimise a distance between embeddings of the anchor transaction haand the positive transaction hpand maximise a distance between embeddings of the anchor transaction haand the negative transaction hn, wherein the distance is a Euclidean distance. Through training the weights of the model are determined to minimise triplet loss. Alternative distance measures may be used instead or additionally, such as any one or more of: Manhattan Distance, Minkowski Distance, and Hamming Distance.

[0065] During training, the feature vectors xp , xvt, xp are passed through the same encoder model 310 in parallel, the model having shared weights for each of the feature vectors. A triplet of embeddings 315-a, 315-p, 315-n is output from the encoder model as a result. This triplet is used together to compute a triplet loss 320. Minimising the triplet loss function pulls together anchor-positive pairs and pushes apart anchor-negative pairs in the embedding space. A triplet loss is calculated using the following equation:

[0066] Where (xp) is the anchor embedding h 315-a, / (xf) is the positive embedding hvt315-p, and / (xp) is the negative embedding / ip 315-n output from the encoder model, and m is a margin. The margin is a value chosen based on experimentation. A Multi-Layer Perceptron (MLP) model, f9iis trained using self-supervised learning. The framework is designed to capture the intricate spending relationships inherent in between transactions without requiring real-time parent transaction lookups. Triplet loss 320 is used for training f9i. Originally proposed in the FaceNet paper [2] the triplet loss is a loss function used primarily in machine learning and deep learning for embedding learning tasks, such as face recognition, image retrieval, and text similarity. The objective of triplet loss is to ensure that samples from the same class (or with similar properties) are closer together in the embedding space, while samples from different classes (or with dissimilar properties) are farther apart. It operates on triplets of samples: an anchor, a positive example (similar to the anchor), and a negative example (dissimilar to the anchor). The loss function aims to minimise the distance between the anchor and the positive example while maximising the distance between the anchor and the negative example. By doing so, it enforces a margin between positive and negative pairs, promoting better discrimination and clustering in the learned embedding space. This technique is particularly useful for tasks that require distinguishing subtle differences between similar items or grouping related items together based on learned features.

[0067] The triplet loss function enables learning meaningful and discriminative embeddings, especially for tasks involving similarity and retrieval. Its foundation lies in probability theory, where the aim is to ensure that the probability of a positive pair (anchor and positive) being closer than a negative pair (anchor and negative) is high. To formalise this, a distance metric d(h, h') is defined, where the distance metric measures a Euclidean distance between two embeddings h and h'.

[0068] A first training stage enforces that the distance between embeddings of the anchor and positive transactions is less than the distance between the anchor and negative transactions by a margin m, which can be expressed as d(ha, hp) + m < d(ha, hn), where / (%“) = h and h is an embedding vector.

[0069] The triplet loss function is thus constructed to enforce this constraint. For a given triplet ha, hp, hn), the triplet loss £ is defined as £ = max(0, d ha, hp) - d(Jia, hn) + ni), where max(0 ) ensures that the loss is non-negative and only contributes when the constraint is violated. By substituting the Euclidian distance into this formula, we obtain £ = max(0, \\ha— hp\\2— \\ha— hn\\2+ m).

[0070] The overall loss for a batch of triplets is computed as the average loss over all triplets in the batch, given by £batch= + m where N is the number of triplets in one training batch. This method ensures that during training, the embeddings of an anchor and its positive counterpart are brought closer together, while the embeddings of an anchor and its negative counterpart are pushed further apart, thereby structuring the embedding space in a way that captures the desired similarities and relationships.

[0071] A second training stage comprises introducing transactions to the encoder model wherein the distance between the anchor transaction haand the positive transaction hpis greater than the distance between the anchor transaction and the negative transaction hn.

[0072] In an embodiment of the present disclosure, positive pairs include parent-child transaction outpoints, while negative pairs are unrelated outpoints. The model is trained to minimise the distance between embeddings of positive pairs and maximise the distance between those of negative pairs. This approach captures transactional lineage, enabling the model to learn spending patterns during training. Consequently, at inference, the model only needs the features of the incoming transaction as it has embedded the spending relationships into its parameters.

[0073] Figure 4 illustrates an example of a structure of the encoder model 115. The three-part feature vector 405 comprising global, local and positional vectors is fed through an input layer 410, a hidden layer 415, and an output layer 420 from which an embedding vector is output.

[0074] Each layer 410, 415, 420 is a fully connected (FC) layer with a rectified linear unit (ReLLI) activation function which introduces a property of non-linearity to a deep learning model. The neural network is shallow, having few layers, yet wide with many neurons in each layer. In essence, the encoder model 115 is a series of matrix multiplications that map the three-part feature vector to an embedding vector in the embedding space. As the three-part feature vector 405 passes the layers 410, 415, 420 of the encoder model, a size of the feature vectors is reduced until an embedding vector is output. In Figure 4, the embedding vector is output from the encoder model with a length of 128.

[0075] Selection of Negative Pairs

[0076] Figure 5 illustrates combinations of triplets of embedding vectors comprising a hard case 500, a semi-hard case 510 and an easy case 520. The triplet of embedding vectors comprises an anchor transaction embedding h , a positive transaction embedding h , and a negative transaction embedding Zi . In one embodiment, the anchor transaction h“and the positive transaction hvtembeddings correspond to a respective parentchild pair of transactions and the negative transaction h comprises an unrelated transaction embedding. The anchor transaction embedding h occupies a location in the embedding space. The location of the positive transaction embedding in the embedding space hvtdefines a Euclidian distance 530 between the anchor and the positive transactions. A Euclidian distance 540 (which is a radial distance) defines a distance from the anchor to the positive plus a margin m in the embedding space.

[0077] The inclusion of the margin m and the careful selection of negative samples are important for creating well-separated and generalisable embeddings. The margin m helps to define a buffer zone that ensures a meaningful separation between positive and negative pairs, preventing the model from merely achieving proximity without significant discrimination. Negative samples are useful for challenging the model during training and ensuring that it learns to distinguish between closely related (positive) and unrelated (negative) transaction outpoints effectively.

[0078] Following the formulation and understanding of triplet loss, the selection of positive and negative pairs is important. Positive pairs are straightforwardly derived from connected transactions in the spending graph, where parent transaction outpoints and their child transaction outpoints form pairs. The selection of negative samples for a given anchor-positive pair, however, is important to training the model effectively [1], [2], [4], A well-chosen negative sample ensures convergence and results in a well-organised and meaningful embedding space, where parent and child transactions are in proximity.

[0079] To achieve this desired embedding space, online hard negative sampling is employed. In this context, "online" refers to the dynamic selection of negative samples during training, based on the current state of the embedding vectors produced by the model. The goal is to select negative samples that are challenging enough to improve the model's performance without causing it to collapse to a single point during training. The negative transactions are therefore constantly re-sampled because the weights of the model change and are updated as the model is being trained.

[0080] There are three categories of negative samples that can be identified, as illustrated in Figure 5:

[0081] Hard Negatives 500: These are samples where the negative outpoint is closer to the anchor than the positive pair in the embedding space. Using hard negatives can be detrimental, as they can cause the model to collapse by learning trivial solutions such as fex) = 0. This occurs because the model becomes overwhelmed by the difficulty of distinguishing between the anchor and the hard negative, leading to incorrect adjustments in the embedding space. Semi-Hard Negatives 510: These are samples where the negative outpoint is further from the anchor than the positive pair but still within a challenging distance. Semi-hard negatives strike a balance by being difficult enough to drive learning but not so hard that they cause the model to collapse. Training on semi-hard negatives allows the model to gradually refine the embedding space, ensuring that the parent and child transactions are correctly clustered without overwhelming the learning process.

[0082] Easy Negatives 520: These are samples where the negative outpoint is already far from the anchor and beyond the margin m in the embedding space. Including easy negatives does not contribute significantly to the learning process because the model can easily distinguish them from positive pairs, leading to little to no gradient and thus slow or stagnant learning is seen.

[0083] To optimise the training process, in a first training stage, the model is trained on semi-hard negatives 510. This approach ensures that the model develops a robust and well-structured embedding space. As training progresses, and the loss function value stagnates, a second training stage is applied which introduces hard negatives to further refine the model and enhance its ability to distinguish between complex transaction relationships. The embedding space contracts when the hard negatives 500 are introduced which leads to clusters forming more tightly. This staged approach helps in achieving a high level of accuracy theoretically possible by utilising hard negatives without the convergence issues of only using hard.

[0084] Data and Preprocessing

[0085] For training, parent-child outpoint pairs were used for triplet loss training. Transaction data from the first ~200k Bitcoin blocks was used, excluding coinbase transactions, yielding 3.5 million transactions, 7.7 million unique outpoints, and 6.2 million unique spent outpoints. Each parent outpoint was paired with all outpoints in its child transactions, resulting in 14 million outpoint pairs. The data was split into training and testing according to an 80 / 20% split. For each set, outliers were identified and removed using the Isolation Forest [5] method, transformed feature distributions using a quantile transformer [6] fitted to training set parameters to achieve uniformity, and standardised all features to the range 0-1. The final datasets resulted in 100k pairs of parent-child transaction outpoints.

[0086] Use Cases and Context

[0087] Sharding a UTXO set and / or received transactions for validation (with respect to a previously sharded UTXO set) are provided as a main example. There are other contexts in which sharding transactions (or subsets thereof) may be of use. Scalable blockchain transaction processing systems are known to use event streaming platforms / systems in order to coordinate the vast inflow of transactions and data across distributed microservices. Kafka is a specific example of such an event streaming platform. Kafka’s distributed messaging architecture is well-suited for this, as it allows the real-time capture, storage, and processing of large volumes of transactional data for downstream validation.

[0088] Blockchain scaling preferably utilises efficient data queuing, load balancing, and fault tolerance. Kafka serves as the messaging infrastructure, enabling various components of the transaction processing node (like transaction validation and block creation) to interact smoothly.

[0089] Kafka’s architecture allows for the distribution of these tasks across a cluster of brokers (servers). Each Kafka broker is responsible for managing specific partitions of data, making it possible to balance the load, replicate data for fault tolerance, and scale horizontally by adding more brokers to the cluster. In scalable blockchain transaction processing architecture, this would mean that incoming transactions, their metadata, and validation information (parent UTXOs) are spread across multiple servers to ensure redundancy and performance.

[0090] Kafka plays a pivotal role in receiving random transactions and queuing them for processing. When a transaction is broadcast to the blockchain network, it is first accepted by Kafka as a message. These messages (transactions) are assigned to partitions within the system, ensuring parallelism and scalability across Kafka’s distributed architecture. Kafka’s brokers manage these partitions and distribute the workload evenly across the system.

[0091] The developed ML model described herein can significantly help in the organisation of incoming transactions in the Kafka system. For example, the model helps to ensure that child transactions are received and stored alongside their respective parent transactions, enhancing Kafka to ensure that these transactions are queued together in the same cluster or shard. Downstream processing uses the relationships between UTXOs within a parent-child hierarchy for accurate transaction validation. As Kafka brokers handle message replication, the transactions are safely stored across multiple brokers to prevent data loss in the event of node failures. A scalable blockchain transaction processing system’s microservices can consume these queued transactions and validate them. It should be noted that the above-mentioned aspects and embodiments illustrate rather than limit the disclosure, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the disclosure as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In the present specification, “comprises” means “includes or consists of” and “comprising” means “including or consisting of”. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The disclosure may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0092] References

[0093] [1] A. Hermans, L. Beyer, and B. Leibe, “In Defense of the Triplet Loss for Person Re- Identification,” ArXiv, Mar. 2017, [Online], Available: http: / / arxiv.org / abs / 1703.07737

[0094] [2] F. Schroff, D. Kalenichenko, and J. Philbin, “FaceNet: A Unified Embedding for Face Recognition and Clustering,” Mar. 2015, doi: 10.1109 / CVPR.2015.7298682.

[0095] [3] A. Vaswani et al., “Attention is all you need,” Adv Neural Inf Process Syst, vol. 2017- Decem, no. Nips, pp. 5999-6009, 2017.

[0096] [4] D. Huang, F. Lei, and X. Zeng, “SimGRL: a simple self-supervised graph representation learning framework via triplets,” Complex and Intelligent Systems, vol. 9, no. 5, pp. 5049-5062, Oct. 2023, doi: 10.1007 / s40747-023-00997-6.

[0097] [5] F. Tony Liu, K. Ming Ting, and Z.-H. Zhou, “Isolation Forest,” Icdm, 2008.

[0098] [6] SciKit-Learn, “QuantileTransformer.” [Online], Available: https : / / scikit- learn.org / stable / modules / generated / sklearn. preprocessing. QuantileTransformer.html

Claims

CLAIMS1 . A computer-implemented method comprising: obtaining a transaction related data point; extracting features of the transaction related data point to determine a feature vector based on the transaction related data point; mapping the feature vector to an embedding space using an encoder model to determine an embedding vector as an output of the encoder model, wherein the encoder model is trained to map related transaction related data points in close proximity to each other within the embedding space; applying a cluster model to the embedding vector, wherein the cluster model is trained to identify and form clusters of transaction related data points across the embedding space, the clusters comprising a plurality of buckets; and assigning the transaction related data point to a one or more buckets based on an output of the cluster model, each bucket having an associated bucket ID.

2. The method of claim 1 , wherein determining a feature vector comprises extracting from the transaction related data point: a global vector comprising global features relating to attributes of a transaction associated with the transaction related data; a local vector comprising local features relating to attributes of an output associated with the transaction associated with the transaction related data; and a positional encoding vector of the transaction related data; and determining a three-part feature vector from the global, local and positional vectors of the transaction related data.

3. The method of claim 2, wherein the attributes of the output associated with the transaction comprise features relating to a locking script of the transaction and wherein extracting the local set of features comprises encoding a vector representation capturing the presence or absence of determined OP codes within the locking script.

4. The method of claim 2 or claim 3, wherein the transaction related data point comprises more than one output: determining a feature vector for each output of the transaction related data point;determining an embedding vector for each feature vector; applying the cluster model separately to each embedding vector; and assigning the transaction related data point to a plurality of buckets based on the outputs of the cluster model for each output of the transaction associated with the transaction related data.

5. The method of any preceding claim, further comprising finding a related transaction related data point of the transaction related data point for validating the transaction related data point, and preferably wherein the related transaction data point is a parent transaction of the transaction related data point.

6. The method of claim 5, wherein if the parent transaction related data point is not in the bucket that the transaction was assigned to, searching one or more buckets which are the nearest neighbours of the bucket for the parent transaction.

7. The method of any preceding claim, wherein the encoder model is trained using selfsupervised learning and the cluster model is trained using unsupervised learning.

8. A method of training an encoder model for mapping related transaction related data points in close proximity to each other within an embedding space, the method comprising: obtaining as an input for the encoder model: a feature vector xp representing an anchor transaction related data point; a feature vector x’’ representing a positive transaction related data point which is related to the anchor transaction related data point; and a feature vector xp representing a negative transaction related data point which is unrelated to the anchor transaction related data point; wherein the method comprises configuring the encoder model to map the feature vectors xp , xvt, xp to an embedding space using the encoder model to output embedding vectors Zip, hvt, h for each of the anchor transaction related data point, the positive transaction related data point, and the negative transaction related data point respectively, wherein an embedding vector is an embedding which describes a location of the transaction related data point in the embedding space; and wherein the method of training includes using a triplet loss approach to: minimise a distance between embeddings of the anchor transaction related data point Zip, and the positive transaction related data point h?; andmaximise a distance between embeddings of the anchor transaction related data point / i“ and the negative transaction related data point h"9. The method of claim 8, wherein a triplet loss is calculated using the following equation:wherein f (%“) is the anchor transaction embedding vector h , fix ) is the positive transaction embedding vector hvt, and f (% ) is the negative transaction embedding vector h output from the encoder model, and m is a margin.

10. The method of claim 8 or claim 9, wherein training the encoder model comprises a first training stage using transactions where the distance between the embedding of the anchor transaction related data point haand the embedding of the negative transaction related data point hnin the embedding space is greater than the distance between the embedding of the anchor transaction related data point and the embedding of the positive transaction related data point hpin the embedding space, but within a specified margin m.

11. The method of claim 8 or claim 9, wherein a triplet loss function is defined as £ = max(0, \\ha- hp\\2- \\ha- hn\\2+ m) and performing the first training stage until the triplet loss function converges.

12. The method of any of claims 9 to 11 , further comprising a second training stage, the second training stage comprising introducing transactions to the encoder model wherein the distance between the anchor transaction related data point haand the positive transaction related data point hpis greater than the distance between the anchor transaction related data point and the negative transaction related data point hn.

13. The method of any of claims 8 to 12, wherein the negative transaction related data point hnis dynamically selected during training based on a current state of the embeddings produced by the model.

14. A network node comprising: memory comprising one or more memory units; andprocessing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any of claims 1 to 7.

15. A computer readable storage medium comprising computer-executable instructions which, when executed, configure a processor to perform the method of any one of claims 1 to 7.

16. A processor configured to execute computer-executable instructions to perform the method of any one of claims 8 to 13 to generate a trained encoder model.

Images