General artificial intelligence application api proxy charging system and charging method thereof

Abstract

The application relates to a general artificial intelligence application API proxy charging system and a charging method thereof, relates to the technical field of artificial intelligence, and comprises a charging terminal and a charging server; the charging terminal is internally provided with a physically unclonable function circuit and a physically unclonable function circuit array, the charging terminal is used for sending an authentication request to the charging server, combining a call record set with a folded signature value to form a signed metering data packet; the charging server is used for sending a random challenge value to the charging terminal and verifying a challenge response value according to a pre-registered challenge response comparison table, and extracting a call record set from a Merkle account book to generate a charging bill at the end of a charging period. The hardware uniqueness of the physically unclonable function circuit is used for realizing device anti-cloning authentication, and the device fingerprint is deeply bound with metering data through iterative folded signature, so that data tamper resistance is realized.

Description

Technical Field

[0001] This disclosure relates to, but is not limited to, the field of artificial intelligence technology, and in particular to a general artificial intelligence application API proxy billing system and its billing method. Background Technology

[0002] Existing application programming interface (API) billing systems are typically deployed in service provider cloud data centers, achieving metering by intercepting and recording user call requests at the interface gateway. This centralized billing architecture establishes a one-way trust relationship between service providers and users. Users can only passively accept bills issued by service providers, lacking the technical means to independently verify the accuracy of billing data. When users dispute bill amounts, because the billing data is entirely controlled by the service provider, users have difficulty obtaining the original call records for verification. Dispute resolution often relies on the service provider's unilateral interpretation. This unequal trust model has become a significant factor hindering the healthy development of the API service market.

[0003] To address the aforementioned trust issues, some technical solutions propose deploying independent billing agent devices on the user side. These devices simultaneously record users' API call behavior, forming a bilateral metering mechanism that mutually corroborates billing data from the service provider side. However, existing billing agent devices generally employ software key-based authentication schemes. For example, digital certificates and private keys are pre-installed at the factory, and the device proves its identity to the billing server through digital signatures. The security of this scheme relies on the confidentiality of the private key. Once the private key is extracted due to firmware vulnerabilities, side-channel attacks, or physical dismantling, attackers can use the leaked private key to forge a legitimate billing agent device and report false metering data to the billing server, thereby committing fraud. Furthermore, software keys can be arbitrarily copied, and the same private key can be cloned and used on multiple devices simultaneously, making it impossible for the billing server to distinguish between legitimate and cloned devices, further exacerbating the security risks of the billing system. Summary of the Invention

[0004] This disclosure provides a general artificial intelligence application API agent billing system and its billing method. It utilizes the hardware uniqueness of physically unclonable function circuits to achieve device anti-cloning authentication, deeply binds device fingerprints and metering data through iterative folding signatures to achieve data anti-tampering, and adopts a Merkle ledger with a jump pointer chain structure to achieve efficient and auditable storage of billing records. It solves the problems of easy forgery of device identity, easy tampering of metering data, and difficulty in auditing billing records in the prior art.

[0005] To solve the above problems, the technical solution of the present invention is implemented as follows: A general-purpose AI application API proxy billing system includes a billing terminal and a billing server. The billing terminal has a built-in physical non-cloning function circuit and a physical non-cloning function circuit array. The billing terminal sends an authentication request to the billing server, inputs a random challenge value into the physical non-cloning function circuit to obtain a challenge response value, intercepts general-purpose AI application API call requests and extracts call records, collects call records according to a preset time window to form a call record set, performs iterative folded signature processing based on the physical non-cloning function circuit array on the call record set to generate a folded signature value, and combines the call record set and the folded signature value to form a signed metering data packet. The billing server sends a random challenge value to the billing terminal and verifies the challenge response value according to a pre-registered challenge response lookup table, performs signature verification on the signed metering data packet, writes the signed metering data packet into a Merkle ledger using a jump pointer chain structure after successful verification, constructs a Merkle tree based on the Merkle ledger and generates an anchored credential, which is returned to the billing terminal. At the end of the billing cycle, the call record set is extracted from the Merkle ledger to generate a billing bill.

[0006] Furthermore, the call record includes the call timestamp, caller identifier, called API identifier, and data transfer volume; the signed metering data packet also includes the start timestamp and end timestamp of the time window.

[0007] Furthermore, the physical non-cloning function circuit array contains 16 independent physical non-cloning function units. The 16 physical non-cloning function units are arranged in a 4x4 matrix structure and numbered sequentially from unit 1 to unit 16. Each physical non-cloning function unit accepts 256-bit input and produces 256-bit output.

[0008] Furthermore, the data preprocessing process of iterative folding signature processing is as follows: all call records in the call record set are arranged in chronological order according to the call timestamp and concatenated end to end to form the original byte stream. Zero-value bytes are padded to the end of the original byte stream until the total length of the original byte stream is an integer multiple of 256 bits to form the padded byte stream. The padded byte stream is divided into 1 data block every 256 bits to form the 1st to Kth data blocks in sequence, where K is the quotient of the total number of bits in the padded byte stream divided by 256.

[0009] Furthermore, the initialization process of the iterative fold signature processing is as follows: initialize a 256-bit status register, the initial value of which is the output value of the billing terminal's device identifier after SHA-256 hash operation; initialize the cell pointer, the initial value of which is 1.

[0010] Furthermore, the iterative execution process of the iterative fold signature processing is as follows: starting from the first data block, each data block is processed sequentially. For the currently processed data block, the current value of the status register is read as the first input value. The first input value is input to the physical non-cloning function cell currently pointed to by the cell pointer to obtain the first response value. The first response value is XORed with the currently processed data block to obtain the first intermediate value. The value of the cell pointer is incremented by 1, and if the value of the cell pointer exceeds 16, the value of the cell pointer is reset to 1. The first intermediate value is input to the physical non-cloning function cell currently pointed to by the cell pointer to obtain the second response value. The second response value is written to the status register to overwrite the original value in the status register. The value of the cell pointer is incremented by 1, and if the value of the cell pointer exceeds 16, the value of the cell pointer is reset to 1. The next data block is processed until the Kth data block is processed. After all data blocks are processed, the final value of the status register is read as the fold signature value.

[0011] Furthermore, the construction process of the jump pointer chain structure is as follows: Perform a SHA-256 hash operation on the signed metering data packet to obtain the current data hash value; read the total number of existing ledger entries in the Merkle ledger, denoted as N; when N equals 0, create the first ledger entry, which contains the signed metering data packet, the current data hash value, and an empty jump pointer set; when N is greater than 0, construct the jump pointer set. The construction process of the jump pointer set is as follows: sequentially check each jump step value in the jump step sequence, which contains 1, 3, 7, 15, and 31. For the currently checked jump step... If N is greater than or equal to S, then read the current data hash value of the ledger entry with sequence number N-S+1 from the Merkle ledger as the hash value of the S-th jump pointer and add it to the jump pointer set; concatenate the current data hash value with all the jump pointer hash values ​​in the jump pointer set in ascending order of jump step value to form a pointer concatenation string, perform SHA-256 hash operation on the pointer concatenation string to obtain the entry anchor hash value; create a ledger entry with sequence number N+1, which contains the signed metering data packet, the current data hash value, the jump pointer set, and the entry anchor hash value.

[0012] Furthermore, the Merkle tree construction process is as follows: the anchor hash values ​​of all ledger entries are sequentially used as leaf nodes of the Merkle tree; starting from the first leaf node, every two adjacent leaf nodes are grouped together, and the anchor hash values ​​of the two leaf nodes in the same group are concatenated in the order of the leaf node numbers and then subjected to SHA-256 hash operation to generate the hash value of the parent node of the same group; if the total number of leaf nodes is odd, the last leaf node is grouped separately, and the hash value of the parent node of the last leaf node group is equal to the anchor hash value of the last leaf node; the above grouping and SHA-256 hash operation process is repeated for all generated parent nodes until only one node remains, and the hash value of the remaining node is used as the Merkle root hash value.

[0013] Furthermore, the anchoring credentials include the Merkle root hash, the sequence number of the ledger entry, and the hashes of all sibling nodes along the path from the leaf node corresponding to the ledger entry to the root node of the Merkle tree, as well as the left and right position markers of all sibling nodes.

[0014] A general AI application API proxy billing method includes the following steps: Step 1, Billing Terminal Identity Authentication: The billing terminal sends an authentication request to the billing server, the billing server sends a random challenge value to the billing terminal, the billing terminal inputs the random challenge value into the physical non-cloning function circuit to obtain the challenge response value, and the billing server verifies the challenge response value according to the pre-registered challenge response lookup table; Step 2, Metering data signing: The billing terminal intercepts API call requests from general artificial intelligence applications and extracts call records. It collects call records according to a preset time window to form a call record set. It performs iterative folding signature processing based on a physically non-clonable function circuit array on the call record set to generate a folded signature value. The call record set and the folded signature value are combined to form a signed metering data packet. Step 3, Billing Data Anchoring: The billing server verifies the signature of the signed metering data packet. After successful verification, the signed metering data packet is written into the Merkle ledger, which uses a skip pointer chain structure. The Merkle tree is constructed based on the Merkle ledger, and anchoring credentials are generated and returned to the billing terminal. Step 4, Billing Bill Generation: At the end of the billing period, the billing server extracts the set of call records from the Merkle ledger, categorizes and summarizes them according to the API identifier of the call to generate billing details, and generates a billing bill according to the preset billing rules.

[0015] This invention discloses a general-purpose artificial intelligence application API proxy billing system and its billing method, which has the following beneficial effects: This invention uses a physically unclonable function circuit as the hardware root of trust for the billing terminal, utilizing inherent process deviations in integrated circuit manufacturing to generate unique challenge response characteristics for each device. Since the response characteristics of the physically unclonable function circuit are determined by the chip's microscopic physical structure, even if an attacker obtains the circuit design drawings and manufacturing process parameters, they cannot replicate a chip with the same response characteristics, fundamentally eliminating the possibility of device cloning and identity forgery. Compared to traditional software key schemes, it has significantly higher security strength.

[0016] This invention designs an iterative folding signature processing method based on a physically non-clonable function circuit array. Through the cyclical invocation of multiple physically non-clonable function units and the hierarchical folding operation of data blocks, the hardware fingerprint information of the billing terminal is deeply integrated into the signature result. This signature method not only proves that the metering data was indeed generated by a specific billing terminal, but also ensures the integrity of the data content. Any tampering with the invocation record will cause the signature verification to fail, achieving dual protection of device binding and data tamper-proofing.

[0017] This invention employs a skip pointer chain structure to construct the Merkle ledger. Each ledger entry contains not only a hash pointer to its direct predecessor entry but also skip pointers to multiple existing entries, forming a multi-layered cryptographic association. This design ensures that any tampering with an existing ledger entry will break the integrity of the hash chain and be detected. Simultaneously, the presence of skip pointers significantly improves the efficiency of historical data verification, allowing the verification process to skip across multiple entries, thus significantly reducing auditing overhead in large-scale ledger scenarios.

[0018] This invention provides billing terminals with cryptographic evidence that metering data has been independently verified as recorded in the ledger through a Merkle tree construction and anchoring credential mechanism. When a billing dispute arises, the billing terminal can present the anchoring credential, allowing any third party to recalculate the Merkle root hash value using the sibling node hash value and position marker in the credential, thus verifying the existence and integrity of the metering data. Dispute arbitration can be completed without trusting the billing server, achieving transparency and auditability in the billing process. Attached Figure Description

[0019] Figure 1 A schematic diagram illustrating the avalanche effect analysis in the iterative folding signature processing process based on a physically non-clonable function circuit array, provided in an embodiment of the present invention. Figure 2 A schematic diagram of the logical topology of the skip pointer chain structure used in the Merkle ledger provided in this embodiment of the invention; Figure 3This is a schematic diagram illustrating the dynamic relationship between API call traffic and buffer data accumulation of the billing terminal under the time window mechanism provided in this embodiment of the invention. Detailed Implementation

[0020] A general-purpose AI application API proxy billing system includes a billing terminal and a billing server. The billing terminal has a built-in physical non-cloning function circuit and a physical non-cloning function circuit array. The billing terminal sends an authentication request to the billing server, inputs a random challenge value into the physical non-cloning function circuit to obtain a challenge response value, intercepts general-purpose AI application API call requests and extracts call records, collects call records according to a preset time window to form a call record set, performs iterative folded signature processing based on the physical non-cloning function circuit array on the call record set to generate a folded signature value, and combines the call record set and the folded signature value to form a signed metering data packet. The billing server sends a random challenge value to the billing terminal and verifies the challenge response value according to a pre-registered challenge response lookup table, performs signature verification on the signed metering data packet, writes the signed metering data packet into a Merkle ledger using a jump pointer chain structure after successful verification, constructs a Merkle tree based on the Merkle ledger and generates an anchored credential, which is returned to the billing terminal. At the end of the billing cycle, the call record set is extracted from the Merkle ledger to generate a billing bill.

[0021] As a core component of the general AI application API proxy billing system, the billing terminal undertakes the critical functions of identity authentication, data collection, and trusted signature. In actual deployment scenarios, the billing terminal typically exists as an embedded hardware device, deployed on the network link between the API gateway and the backend server. All general AI application API call requests passing through this link must be forwarded through the billing terminal, thereby achieving full capture and metering of API call behavior.

[0022] The billing terminal's hardware architecture is built upon a security chip design philosophy. In a typical implementation, the billing terminal uses an ARM Cortex-A53 quad-core processor as the main controller, with a clock speed of 1.2 GHz, 2 gigabytes of DDR4 memory for runtime data caching, and 16 gigabytes of eMMC flash memory for firmware storage and log recording. The billing terminal connects to the network via a Gigabit Ethernet interface, supporting full-duplex communication mode, with a theoretical maximum throughput of 1000 megabits per second. In high-concurrency application scenarios, the billing terminal can also use a 10 Gigabit Ethernet interface to meet higher data transmission requirements.

[0023] The billing terminal incorporates a physically unclonable function (PCF) circuit, which utilizes unavoidable process variations in integrated circuit manufacturing to generate unique circuit response characteristics. Because parameters such as doping concentration, oxide layer thickness, and interconnect width exhibit nanometer-level random fluctuations during semiconductor manufacturing, even with identical design layouts and manufacturing processes, PCF circuits on different chips will display drastically different input-output mappings. This characteristic based on physical randomness gives PCF circuits a natural anti-cloning capability; even if an attacker obtains the circuit design drawings, they cannot replicate a chip with the same response characteristics.

[0024] The core structure of the physically non-clonable function (PCF) circuit employs an arbiter-type design. In this design, the input signal simultaneously enters two symmetrically arranged delay paths, each consisting of several stages of switchable delay units connected in series. When a bit of the input challenge value is 0, the corresponding delay unit selects the first sub-path; when that bit is 1, the second sub-path is selected. Due to manufacturing process variations, there is a slight difference in the total delay time between the two delay paths. This difference is captured by the arbiter latch circuit at the end of the path and converted into a 1-bit digital output. By cascading multiple such arbiter structures, the PCF circuit can map a 256-bit input challenge value to a 256-bit output response value.

[0025] Before leaving the factory, the billing terminal undergoes a registration process for its physically unclonable function (PUC) circuitry characteristics. This process is executed in a controlled production environment, where the production equipment sequentially sends a preset sequence of challenge values ​​to the billing terminal and records the sequence of response values ​​output by the PUC circuitry. In one specific implementation, the registration process uses 10,000 challenge values, each a 256-bit pseudo-random number. Because the response of the PUC circuitry contains a certain degree of noise, the same challenge value may produce slightly different response values ​​under different ambient temperatures or supply voltages. Therefore, the registration process is repeatedly executed under various combinations of conditions, ranging from -40 degrees Celsius to +85 degrees Celsius and from 0.9 volts to 1.1 volts, and the statistical distribution of the response values ​​for each challenge value under various conditions is recorded. Finally, the device identifier of the billing terminal and the challenge response lookup table of its PUC circuitry are securely stored in the trusted database of the billing server.

[0026] The process of a billing terminal sending an authentication request to the billing server follows a challenge-response protocol. When the billing terminal powers on or needs to establish a new communication session, it first sends an authentication request message containing its own device identifier to the billing server through a secure channel. The device identifier is a unique 96-bit code, where the first 32 bits represent the device manufacturer code, the middle 32 bits represent the product model code, and the last 32 bits represent the device serial number. After receiving the authentication request, the billing server retrieves the challenge-response lookup table corresponding to the device identifier from its local database, and randomly selects a challenge value from the lookup table as the random challenge value for this authentication, sending it to the billing terminal through the secure channel.

[0027] After receiving a random challenge value, the billing terminal inputs it into its built-in physically unclonable function circuit. This circuit processes the random challenge value based on its inherent physical characteristics and outputs a uniquely corresponding challenge response value. This response value is also a 256-bit binary data set. The billing terminal then transmits the challenge response value back to the billing server via a secure channel.

[0028] After receiving the challenge response value, the billing server compares it with the expected response value corresponding to that random challenge value in a pre-registered challenge response lookup table. Considering the inherent response noise in physically non-cloning function circuits, the comparison process allows for a certain degree of fault tolerance. In one implementation, verification is considered successful when the Hamming distance between the challenge response value and the expected response value is less than or equal to a preset fault tolerance threshold. The Hamming distance represents the number of bits that differ at corresponding positions in two equal-length binary strings; the fault tolerance threshold is typically set to 5% to 10% of the total number of bits in the response value, i.e., 12 to 25 bits. If the actual Hamming distance exceeds the fault tolerance threshold, verification is considered a failure, the billing server refuses to establish a communication session, and records an anomaly in the log.

[0029] After successful verification, a communication session is established between the billing server and the billing terminal. During the session's validity period, all data exchange between the billing terminal and the billing server occurs through this session. The session validity period is typically set to 3600 seconds, or 1 hour. After the session expires, the billing terminal needs to re-initiate an authentication request to establish a new session. This periodic re-authentication mechanism effectively prevents session hijacking attacks; even if an attacker intercepts a communication session at a certain point, they cannot continue to impersonate a legitimate billing terminal after the session expires.

[0030] After completing identity authentication, the billing terminal enters the working state of API call interception and metering data collection. The billing terminal performs packet interception at the transport layer of the network protocol stack, identifying general AI application API call requests through deep packet inspection (DPI) technology. In a typical deployment scenario, the general AI application API is carried by the HTTPS protocol, the target port of the request message is 443, and the request path follows the RESTful style, such as " / v1 / chat / completions" or " / v1 / embeddings". The billing terminal determines the API service provider accessed by parsing the Server Name Indicator extension field in the TLS handshake process and the Host field in the HTTP request header; it also determines the specific API interface being called by parsing the URI path in the HTTP request line.

[0031] For each intercepted general AI application API call request, the billing terminal extracts and records the following call record information: call timestamp, caller ID, called API ID, and data transmission volume.

[0032] The call timestamp is represented by a 64-bit unsigned integer, recording the precise moment the API call request arrived at the billing terminal. The unit of the timestamp is nanoseconds, with the starting base being Unix epoch time, i.e., January 1, 1970, 00:00:00 (Coordinated Universal Time). The reason for using nanosecond-level precision is that in high-concurrency scenarios, a large number of API call requests may be generated in a very short time. Millisecond-level precision cannot distinguish the order of multiple requests within the same millisecond, while nanosecond-level precision provides sufficient time resolution. The billing terminal has a built-in high-precision real-time clock chip, which maintains synchronization with the upstream time server via a network time protocol, with a clock drift rate of less than 1 millisecond per day.

[0033] The caller identifier is used to uniquely identify the user or application initiating the API call request. In one implementation, the caller identifier is derived from the API key assigned by the API service provider. The billing terminal extracts the API key from the "Authorization" field of the HTTP request header, performs a SHA-256 hash operation on the API key, and uses the first 128 bits of the hash result as the caller identifier. The reason for using hash derivation instead of directly using the API key is to protect user privacy; even if billing data is leaked, attackers cannot reverse engineer the user's API key from the caller identifier. In another optional implementation, the caller identifier can also be extracted from the client identifier field in the OAuth 2.0 access token.

[0034] The API call identifier is used to distinguish different types of API interfaces. Since the billing rates for different API interfaces may vary, accurately recording the API call identifier is crucial for subsequent cost calculations. The API call identifier is obtained by concatenating the API service provider's domain name and the API path, followed by normalization. Normalization includes: converting the domain name to lowercase, removing query parameters from the API path, and replacing variable parameters in the path with placeholders.

[0035] The data transmission volume records the network traffic generated by this API call, including both request and response data volumes. The request data volume is the length of the HTTP message body of the API call request message, in bytes; the response data volume is the length of the HTTP message body of the API call response message, also in bytes. For response messages using chunked transfer encoding, the billing terminal needs to accumulate and calculate the response data volume after receiving all data blocks. Accurate measurement of data transmission volume is crucial for traffic-based billing scenarios. Some API service providers bill based on the number of input and output tokens rather than the number of bytes. The billing terminal can also record the number of tokens in the data transmission volume field; the specific measurement method is determined by the billing rule configuration.

[0036] The billing terminal collects call records according to a preset time window to form a call record set. The time window refers to the time interval during which the billing terminal accumulates call records and performs batch processing. In one implementation, the time window length is set to 60 seconds, meaning the billing terminal performs batch signature processing on all call records collected within the past 60 seconds every 60 seconds. The time window length needs to strike a balance between real-time performance and processing efficiency: a time window that is too short will lead to excessively frequent signature processing, increasing computational overhead; a time window that is too long will delay the reporting of billing data, reducing the system's real-time performance. In optional implementations, the time window length can also be set to 30 seconds, 120 seconds, or 300 seconds, with the specific value determined based on the needs of the actual business scenario.

[0037] The start and end timestamps of a time window mark its boundaries. The start timestamp is the call timestamp of the earliest call record within the time window, rounded down to the time window granularity. The end timestamp is the start timestamp plus the time window length. For example, if the time window length is 60 seconds, and the call timestamp of a certain call record is "2024-01-15 10:23:47.123456789", then the start timestamp of the time window to which this call record belongs is "2024-01-15 10:23:00.000000000", and the end timestamp is "2024-01-15 10:24:00.000000000".

[0038] The billing terminal maintains a call record buffer in memory to temporarily store call records collected within the current time window. The call record buffer is implemented using a circular queue data structure with a queue capacity of 100,000 records, sufficient to handle approximately 1600 API calls per second. When a new call record arrives, the billing terminal appends it to the tail of the circular queue. When the time window ends, the billing terminal reads all call records from the circular queue for the current time window, clears the queue, and begins data collection for the next time window.

[0039] refer to Figure 3 This chart uses a hybrid Y-axis format, with the horizontal axis representing time in seconds, covering multiple consecutive time windows. The left vertical axis represents the instantaneous number of API call requests, corresponding to the gray bars in the chart; the right vertical axis represents the amount of data awaiting signature accumulated in the billing terminal's memory buffer, corresponding to the black line graph. The chart clearly marks the boundaries of the time windows, such as the vertical dashed lines at 60, 120, and 180 seconds, dividing the time axis into several independent billing periods. The gray bars exhibit obvious pulse characteristics and randomness, reflecting the uneven arrival of general AI API call requests in real-world application scenarios. It can be seen that dense request peaks occur at certain times, while they are relatively sparse at other times, consistent with the bursty characteristics of real network traffic. Correspondingly, the black line graph depicts the sawtooth wave pattern of the buffer state. At the beginning of each time window, the accumulated data in the buffer is zero.

[0040] As API requests, represented by the gray bars, arrive continuously, the billing terminal extracts call records in real time and stores them in a buffer, causing the black line to exhibit a stepped or sloping upward trend. Notably, the slope of the line is positively correlated with the API request density at that time: in areas of high traffic, the line rises steeply; in areas of low traffic, the line rises gently. This correspondence visually illustrates the data capture and caching process of the billing terminal. When the time reaches the window boundary (e.g., at the 60th second), the black line in the graph instantly drops vertically to zero. This characteristic change corresponds to the billing terminal triggering a batch processing mechanism: the terminal stops writing data for the current window, packages all call records in the buffer, performs iterative signature folding based on a physically non-clonable function array, generates a signed metering data packet and reports it, and then clears the buffer to prepare for receiving data from the next time window. This periodic "accumulation-clearing" cycle forms a regular sawtooth waveform in the graph. The graph also implicitly analyzes system resource utilization. The peak height of the broken line represents the maximum memory capacity requirement within that time window, while the window length directly affects the peak value and reset frequency. This graph provides a clear understanding of how this invention uses a time window mechanism to transform discrete, high-concurrency API call streams into ordered, batched metering data blocks, thereby balancing real-time performance with system processing overhead and ensuring the stability and data integrity of the billing system even under conditions of significant traffic fluctuations.

[0041] The billing terminal performs iterative folded signature processing on the call record set based on a physically non-clonable function circuit array to generate a folded signature value. Iterative folded signature processing is a signature algorithm designed specifically for billing scenarios. Its core idea is to combine the hardware uniqueness of physically non-clonable function circuits with the data integrity protection of hash chains to generate a signature value that has both device binding and tamper-proof characteristics.

[0042] Physically non-cloning function (PTC) circuit arrays form the hardware foundation for iterative folded signature processing. Unlike a single PTC circuit used for authentication, a PTC circuit array consists of multiple independent PTC units, each with its own independent physical characteristics. In one specific implementation, the PTC circuit array contains 16 independent PTC units arranged in a 4x4 matrix structure, numbered sequentially from unit 1 to unit 16. This matrix layout design improves chip layout regularity and facilitates fast addressing of specific PTC units using a combination of row and column addresses.

[0043] Each physically non-cloning function (PTC) cell accepts 256 bits of input and produces 256 bits of output. The 256-bit input / output width matches the digest length of the SHA-256 hash algorithm. This design allows the output of the PTC cell to be directly manipulated bitwise with the hash result without bit width conversion, simplifying hardware implementation complexity. The 16 PTC cells are physically independent on the chip, maintaining sufficient spacing to ensure that the randomness of manufacturing process variations is uncorrelated between cells, thereby improving the overall array security.

[0044] The first stage of iterative signature folding processing is data preprocessing. The billing terminal arranges all call records in the call record set according to the order of their call timestamps. A stable sorting algorithm is used to ensure that call records with the same timestamp maintain their original relative order. After sorting, the billing terminal concatenates the call records end-to-end to form a raw byte stream. Before concatenation, each call record is converted into a byte sequence according to a predefined serialization format: 8 bytes for the call timestamp, 16 bytes for the caller identifier, a variable-length API identifier (with a 2-byte length field at the beginning), and 8 bytes for the data transmission amount. The length of the raw byte stream formed after concatenating the call records depends on the number of call records within the time window and the average length of the API identifiers being called.

[0045] The original byte stream needs to be padded to meet the alignment requirements of subsequent block processing. The billing terminal padded the end of the original byte stream with zero-value bytes until the total length of the original byte stream is an integer multiple of 256 bits (i.e., 32 bytes), forming a padded byte stream. The padding rules follow these conventions: first, a byte with a value of 0x80 is appended to the end of the original byte stream as a padding start marker; then, several bytes with a value of 0x00 are appended until the total length meets the alignment requirements; finally, 8 bytes are used to record the original length of the original byte stream (in bits, big-endian). This padding rule borrows from the SHA-256 algorithm's padding scheme, ensuring that original data of different lengths will not produce the same padded byte stream after padding, thus avoiding signature collisions.

[0046] After padding, the byte stream is divided into blocks of 256 bits each. The division begins at the start of the padded byte stream, with each consecutive 256 bits forming a data block, sequentially forming the first data block, the second data block, and so on. Data blocks. Total number of data blocks. The calculation method is to divide the total number of bits in the padded byte stream by 256, that is... ,in This indicates the total number of bits in the padded byte stream. In a typical application scenario, if a single time window contains 1000 call records, and the average serialization length of each call record is 50 bytes, then the original byte stream length is approximately 50,000 bytes (400,000 bits), and the padded byte stream is approximately 400,064 bits. The total number of data blocks... Approximately 1563.

[0047] The second stage of the iterative folded signature processing is state initialization. The billing terminal initializes a 256-bit state register, which stores intermediate state values ​​during the iterative calculation. The initial value of the state register is set to the output value of the billing terminal's device identifier after a SHA-256 hash operation. The device identifier is 96 bits. Before performing the hash operation, the billing terminal pads the device identifier with 160 zero bits to form a 256-bit hash input. The reason for choosing the hash value of the device identifier as the initial value of the state register is that this binds the signature result to a specific billing terminal device. Even if different billing terminals process the exact same set of call records, they will generate different folded signature values, thus achieving device-level signature anti-counterfeiting.

[0048] The billing terminal simultaneously initializes a cell pointer, which indicates which physically non-cloning function (PNC) cell in the PNC circuit array should be used in the current iteration step. The cell pointer's value ranges from 1 to 16, with an initial value of 1, pointing to the first PNC cell. The cell pointer uses a cyclic incrementing update strategy; when its value reaches 16 and increments again, it is reset to 1, and this process repeats. This design, which uses 16 PNC cells cyclically, fully utilizes the independent randomness of each cell in the PNC circuit array, enhancing the unpredictability of the signature.

[0049] The third stage of iterative signature folding processing is iterative execution. Starting with the first data block, the billing terminal performs the same iterative operation on each subsequent data block. Taking data block processing as an example, where For those between 1 and To find positive integers between [a certain value] and [a certain value], the specific steps are as follows: The billing terminal reads the current value of the status register as its first input value. This first input value is 256 bits of binary data, reflecting the previous... The accumulated state after processing each data block. For the processing of the first data block, the first input value is the initial value of the status register.

[0050] The billing terminal inputs the first input value to the physical non-cloning function unit currently pointed to by the input unit pointer, and the physical non-cloning function unit outputs a first response value. The first response value is 256 bits of binary data, determined by the inherent physical characteristics of the physical non-cloning function unit. Since each physical non-cloning function unit has a unique and non-replicable input-output mapping relationship, the first response value contains the hardware fingerprint information of the billing terminal.

[0051] The billing terminal will compare the first response value with the second response value. The data block undergoes a bitwise XOR operation to obtain the first intermediate value. The bitwise XOR operation involves performing a logical XOR operation on corresponding bits of two 256-bit binary numbers: the result is 0 when the two bits are the same, and 1 when they are different. The bitwise XOR operation is reversible, meaning that if the first intermediate value and the second intermediate value are known, the result can be obtained. The first response value can be derived from the data block, but this reversibility is only mathematically valid. In actual attacks, due to the uncopyability of physically non-clonable function units, attackers cannot exploit this reversibility to forge signatures. The introduction of the bitwise XOR operation encodes the data content in the call record set into the iterative computation process, meaning that any modification to a data block will lead to a change in the final signature value.

[0052] After completing the first physically non-cloning function unit call, the billing terminal updates the unit pointer. The update rule is: increment the unit pointer value by 1; if the unit pointer value exceeds 16, reset the unit pointer value to 1. This update strategy requires subsequent iterations to use different physically non-cloning function units, increasing the complexity of the signature.

[0053] The billing terminal inputs the first intermediate value to the physical non-cloning function unit currently pointed to by the input unit pointer, and the physical non-cloning function unit outputs the second response value. Since the unit pointer has been updated, the physical non-cloning function unit used in this call is different from the previous one. This means that even if the first intermediate value is exactly the same as the first input value in the previous call, the output second response value will differ due to the use of a different physical non-cloning function unit. This dual-call design further enhances the security strength of the signature.

[0054] The billing terminal writes the second response value to the status register, overwriting the original value in the status register. The update of the status register marks the... Once the data block processing is complete, the updated status register value will be used as the processing value for the next data block. The first input value when processing a data block. Through this state propagation mechanism, the processing results of previous data blocks are accumulated in the processing of subsequent data blocks, forming a chain dependency.

[0055] The cell pointer is updated again after the second response value is written to the status register, following the same update rules as described above. Thus, the [number]th [unit / process / etc.]... Once the data block processing is complete, the billing terminal continues processing the next data block. Data block, repeat the above steps until the first one. Data block processing complete.

[0056] The iterative execution process of iterative signature folding can be described in a more formal way. Let... This indicates the initial value of the status register. Indicates the first Data blocks, Indicates the first The input-output mapping function of the physical non-clonable function unit. Indicates processing the first The value of the pointer to the previous cell in the data block. The data block processing procedure can be represented as follows: First, calculate the first response value. ,in To process the first The value of the status register before the data block.

[0057] Then calculate the first intermediate value. ,in This indicates a bitwise XOR operation.

[0058] Next, update the cell pointer. ,Right now for The result of adding 1, taking the modulo of 16, and then adding 1 again.

[0059] Then calculate the second response value. .

[0060] Update status register .

[0061] Finally, update the cell pointer again. .

[0062] all After each data block is processed, the billing terminal reads the final value of the status register. This serves as the folded signature value. The folded signature value is 256 bits of binary data, containing a data digest of the call record set and the hardware fingerprint information of the billing terminal. Due to the chain-dependent nature of the iterative computation process, any modification to a data block will trigger an avalanche effect, causing a significant change in the folded signature value, thereby protecting the integrity of the call record set.

[0063] refer to Figure 1The graph is presented in a Cartesian coordinate system, where the horizontal axis represents the sequence number of the processed data block, i.e., the number of iterations, and the vertical axis represents the bit flip rate or difference rate of the status register, in percentage form. This curve visually reflects the diffusion process of the change in the system's internal status register value as iterative folding signature processing progresses through the physically non-cloning function circuit array when the input data block undergoes a small change, such as a single bit flip.

[0064] In the initial stage illustrated, the diffusion stage, the curve exhibits a steep upward trend. This corresponds to the first few data block cycles of the iterative processing. During this stage, due to the high nonlinearity and sensitivity to small input perturbations of the physically non-cloning function (PTC) circuit, the initial single-bit difference is rapidly amplified after processing by the first PTC unit, XORing with the data block, and subsequent processing by another PTC unit. The number of difference bits in the status register grows approximately exponentially with the number of iterations. This phenomenon is known as the avalanche effect in cryptography, indicating that the algorithm possesses good confusion and diffusion properties.

[0065] As the iteration process enters the middle stage, the rising slope of the curve gradually slows down and begins to oscillate. This is because the difference rate of the state register is approaching its theoretical limit. The dashed line in the figure represents the ideal avalanche state, i.e., a difference rate of 50%. This means that, ideally, a change in input at any point should cause about half of the bits in the output to flip, making it impossible for an attacker to infer the difference in input from the difference in output. The experimental data shown by the solid line indicates that the bit flip rate of the state register of the iterative folding signature scheme of this invention converges rapidly and stabilizes at around 50% after processing about 15 to 20 data blocks. The oscillation in the figure reflects the randomness introduced by the physical noise inherent in physically non-clonable function circuits, which to some extent enhances the unpredictability of the signature. After entering the stable stage, the curve fluctuates slightly around the 50% baseline, indicating that the internal state of the system has now achieved complete randomization and obfuscation. At this point, any statistical characteristics of the original input data have been completely erased, and the processing of each subsequent data block will maintain this high-entropy state. This figure fully demonstrates that the iterative folding signature algorithm based on a physically non-clonable function array proposed in this invention can effectively resist differential power analysis attacks and linear analysis attacks, ensuring the security and non-forgeability of billing data signatures, and providing a solid cryptographic foundation for the subsequent generation of signed metering data packets.

[0066] After completing the iterative folded signature processing, the billing terminal combines the call record set, the start timestamp of the time window, the end timestamp of the time window, and the folded signature value to form a signed metering data packet. The data structure of the signed metering data packet is organized as follows: bytes 1 to 8 represent the start timestamp of the time window, bytes 9 to 16 represent the end timestamp of the time window, bytes 17 to 20 represent the number of call records (a 32-bit unsigned integer), bytes 21 onwards represent the serialized data of the call records, followed immediately by the 32-byte folded signature value. The total length of the signed metering data packet depends on the number of call records and the serialization length of each call record.

[0067] Signed metering data packets are reported to the billing server via a communication session. The reporting process uses TLS 1.3 for encrypted transmission, ensuring that the signed metering data packets are not eavesdropped on or tampered with during transmission. After successfully reporting the signed metering data packets, the billing terminal clears the call record cache for that time window from memory, freeing up storage space for data collection in the next time window. If the reporting process fails due to network failure, the billing terminal temporarily stores the signed metering data packets in the local flash memory's pending reporting queue. Once the network is restored, the data packets are re-reported in a first-in, first-out order, ensuring that metering data is not lost due to network interruption.

[0068] As the central node of the general-purpose AI application API proxy billing system, the billing server undertakes core functions such as identity verification, signature verification, ledger management, and bill generation. In actual deployment, the billing server typically adopts a high-availability cluster architecture, consisting of multiple physical servers or virtual machines, providing a unified service entry point through a load balancer. A typical hardware configuration for a single billing server is as follows: dual Intel Xeon Platinum 8380 processors, each with 40 physical cores and a clock speed of 2.3 GHz; 512 gigabytes of DDR4 ECC memory for high-speed caching of challenge response lookup tables and hot ledger data; and eight 3.84 terabyte NVMe solid-state drives forming a RAID10 array, providing approximately 15 terabytes of effective storage capacity and 3 million random read / write operations per second.

[0069] The billing server operates on a Linux distribution with a kernel version of at least 5.15 to ensure good support for new hardware and security features. The billing service application is written in Rust, fully leveraging the language's memory safety features and zero-cost abstraction capabilities to achieve near-native code execution efficiency while maintaining system security. The application runs in a multi-threaded asynchronous model. The main thread listens for network connection requests, while a worker thread pool handles the specific authentication and billing business logic. The thread pool size dynamically adjusts based on the number of processor cores, with a default configuration of twice the number of physical cores.

[0070] The process of the billing server sending a random challenge value to the billing terminal occurs after the billing terminal initiates an authentication request. When the billing server receives the authentication request message from the billing terminal, it first parses the terminal's device identifier from the message. The device identifier is a unique 96-bit code. The billing server retrieves the corresponding record in the challenge-response lookup table database based on this device identifier. The challenge-response lookup table database is implemented using a key-value storage engine, with the device identifier as the primary key and the corresponding challenge-response lookup table as the value. A single billing terminal's challenge-response lookup table typically contains 10,000 challenge-response records. Each record consists of a 256-bit challenge value and a 256-bit expected response value. Each record occupies 64 bytes, and the entire lookup table occupies approximately 640 kilobytes of storage space.

[0071] The billing server randomly selects a record from the retrieved challenge-response lookup table and uses the challenge value in that record as the random challenge value for this authentication. The random selection process employs a cryptographically secure pseudo-random number generator. This generator uses the system entropy pool as a seed source and outputs uniformly distributed random index values ​​ranging from 0 to 9999. The reason for using a cryptographically secure random number generator instead of a regular one is that if the selection of the random challenge value is predictable, an attacker could pre-obtain the expected response value and launch a replay attack. The billing server encapsulates the selected random challenge value into an authentication challenge message and sends it to the billing terminal through the established secure channel.

[0072] While sending a random challenge value, the billing server records relevant information for this authentication session in its local session state table, including: the billing terminal's device identifier, the random challenge value, the challenge sending timestamp, the expected response value, and the session state flag. The initial value of the session state flag is set to "Waiting for Response". The session state table is implemented using an in-memory hash table, with the session identifier as the key. The session identifier is generated by concatenating the billing terminal's device identifier and the challenge sending timestamp, followed by a hash operation. The billing server sets a timeout threshold for each authentication session, with a default value of 30 seconds. If no response is received from the billing terminal within the timeout threshold, the session is marked as "Timeout Failed" and removed from the session state table.

[0073] After receiving the challenge response value from the billing terminal, the billing server verifies its correctness against a pre-registered challenge response lookup table. The verification process begins by retrieving the corresponding authentication session record from the session state table to obtain the expected response value for that session. The expected response value is the standard response value output by the physical non-cloning function circuit for that random challenge value during the billing terminal's factory registration. Ideally, the challenge response value returned by the billing terminal should perfectly match the expected response value. However, due to inherent response noise in the physical non-cloning function circuit, the actual returned challenge response value may differ from the expected response value by a few bits.

[0074] Response noise originates from the combined effects of various physical factors. Changes in ambient temperature alter the semiconductor carrier mobility, thus affecting the timing characteristics of the delay path; fluctuations in supply voltage change the transistor's switching threshold, causing the arbitrator's decision to flip at a critical state; electromagnetic interference can introduce transient noise into the signal transmission path, interfering with the sampling results of the latch circuit. These factors cause physically non-clonable function circuits to output slightly different response values ​​at different times for the same challenge value, with the number of differing bits typically fluctuating between 2% and 5% of the total number of bits.

[0075] To accommodate response noise from physically non-clonable function circuits, the billing server uses Hamming distance as a metric for response value similarity. Defined as the number of bits at corresponding positions that differ in two binary strings of equal length. Let the challenge response value be... The expected response value is The Hamming distance between the two is calculated as follows: First, for... and Perform a bitwise XOR operation to obtain the difference vector. The bits with a value of 1 in the difference vector represent the positions where the two response values ​​are inconsistent; then the difference vector is statistically analyzed. The number of bits with a value of 1 in the middle is the Hamming distance. .

[0076] Setting fault tolerance thresholds for billing servers Used to determine the verification result. Fault tolerance threshold. The value of the fault tolerance threshold needs to strike a balance between security and availability: setting it too low can cause legitimate billing terminals to be misidentified as illegitimate devices due to response noise, resulting in a denial of service; setting it too high will reduce the ability to identify counterfeit devices and increase security risks. In one specific implementation, the fault tolerance threshold... Set to 8% of the total number of bits in the response value, that is, for a 256-bit response value. The threshold allows a difference of no more than 20 bits between the challenge response value and the expected response value. This tolerance threshold is selected based on the fact that, under normal circumstances, the response noise rate of a physically non-clonable function circuit is approximately 3% to 5%. Using 8% as the tolerance threshold ensures a high probability of passing authentication for legitimate devices, while keeping the probability of counterfeit devices passing verification within an acceptable range.

[0077] When Hamming distance Less than or equal to the fault tolerance threshold When the authentication is successful, the billing server updates the session status to "authentication successful" and returns an authentication success message to the billing terminal, thus formally establishing the communication session. When the Hamming distance... Greater than the fault tolerance threshold When authentication fails, the billing server determines that the authentication has failed, updates the session status to "authentication failed," returns an authentication failure message to the billing terminal, and records it in the security audit log. Billing terminals that fail authentication multiple times consecutively will be temporarily blacklisted, and their subsequent authentication requests will be rejected during the cooldown period. The default cooldown period is 300 seconds, which doubles with each consecutive failure, with a maximum of 86,400 seconds.

[0078] After a communication session is successfully established, the billing server waits to receive the signed metering data packet reported by the billing terminal. The signed metering data packet is transmitted through a secure channel. Upon receiving the packet, the billing server first performs a format check to confirm that the packet structure conforms to the predefined serialization specification and that the length and value range of each field are within a reasonable range. After the format check passes, the billing server verifies the signature of the signed metering data packet to confirm that the packet was indeed generated by the claimed billing terminal and that its content has not been tampered with.

[0079] The response mapping data of the physically non-cloning function (PTC) circuit array is collected synchronously and stored in the billing server during the billing terminal's factory registration. Since the PTC circuit array contains 16 independent PTC units, each PTC unit requires independent collection of response mapping data. The method for collecting the response mapping data of a single PTC unit is as follows: a series of challenge values ​​covering all possible input spaces are input to the unit, and the corresponding response values ​​are recorded. Considering that the 256-bit input space contains... Given the finite number of possible input values, exhaustive collection is impractical. Therefore, the factory registration process uses a finite number of sampling challenge values, typically 1,000,000. These challenge values ​​are generated using a cryptographically secure pseudo-random number generator to ensure uniform distribution across the input space.

[0080] During signature verification, the billing server needs to query the response output of the physically unclonable function unit for a specific input value. If the input value happens to be in the sampled challenge value set during factory registration, the registered response value is returned directly. If the input value is not in the sample set, the billing server uses a machine learning-based response prediction model for inference. The response prediction model is trained on sampled data during the factory registration phase. The model architecture is a multilayer perceptron neural network, with 256 neurons in the input layer corresponding to each bit of the 256-bit input value, 256 neurons in the output layer corresponding to each bit of the 256-bit response value, and three hidden layers with 512 neurons each. The activation function is ReLU. The trained model parameters and sampled response data are stored on the billing server for querying the response value during signature verification.

[0081] The billing server performs signature recalculation following the same process as the billing terminal. All call records in the call record set are arranged in chronological order by call timestamp and concatenated end-to-end to form the original byte stream. Zero-value bytes are padded to the end of the original byte stream until its total length is a multiple of 256 bits, forming the padded byte stream. The padded byte stream is then divided into data blocks of 256 bits each. A 256-bit status register is initialized with the SHA-256 hash value of the billing terminal's device identifier; cell pointers are also initialized with an initial value of 1. Each data block is processed sequentially, starting from the first data block. During processing, the response values ​​of each physically unclonable function unit are obtained by querying response mapping data or calling the response prediction model. After all data blocks have been processed, the billing server obtains the recalculated folded signature value.

[0082] The billing server compares the recalculated folded signature value with the folded signature value carried in the already signed metering data packet. Due to the inherent prediction error in the response prediction model and the potential slight fluctuations in the response of a physically non-cloning function circuit array at different times, the billing server also employs a Hamming distance-based fault-tolerant comparison method. The fault tolerance threshold for signature verification is set to 5% of the total number of bits in the folded signature value; that is, for a 256-bit folded signature value, the fault tolerance threshold is 12 bits. If the Hamming distance between the recalculated folded signature value and the carried folded signature value is less than or equal to the fault tolerance threshold, the signature verification passes; otherwise, the signature verification fails, the billing server discards the signed metering data packet, and records the anomaly in the log.

[0083] After successful signature verification, the billing server writes the signed metering data packet into a Merkle ledger using a skip pointer chain structure. The Merkle ledger is a tamper-proof data structure designed for high-frequency append-only scenarios. It links ledger entries together using a cryptographic hash chain; any tampering with an existing entry will break the integrity of the hash chain and be detected. The skip pointer chain structure is an enhancement to the traditional unidirectional hash chain, providing more efficient historical data verification capabilities while maintaining tamper-proof properties.

[0084] In a traditional one-way hash chain, each entry contains only a hash pointer to the previous entry. Verifying the integrity of a historical entry requires verifying each entry sequentially from that entry to the latest entry, resulting in a time complexity of O(n log n). ,in This represents the number of entries between the current entry and the latest entry. For large-scale ledgers containing millions of entries, this linear verification overhead is unacceptable. The skip pointer chain structure, by maintaining several additional skip pointers in each entry, allows the verification process to proceed in leaps across multiple entries, reducing the time complexity to [value missing]. .

[0085] The construction process of the jump pointer chain structure is as follows: The billing server first performs a SHA-256 hash operation on the signed metering data packet to obtain the current data hash value. SHA-256 is a widely used cryptographic hash function that can map input data of arbitrary length to a fixed-length 256-bit hash value, possessing security features such as collision resistance and image attack resistance. The current data hash value uniquely identifies the content of the signed metering data packet; any minor modification to the packet content will cause a significant change in the current data hash value.

[0086] refer to Figure 2This diagram constructs a multi-level directed acyclic graph (DAG) structure using nodes and connecting lines, vividly revealing the complex hash reference relationships between ledger entries. A series of horizontally arranged circular nodes represent ledger entries appended chronologically. The labels within the nodes, such as N, N-1, N-2, etc., indicate the entry's sequence number, where N represents the latest entry, N-1 represents its predecessor, and so on. The diagram shows two different types of connecting lines, representing hash pointers of different natures. Solid arrows connecting adjacent nodes represent a basic unidirectional hash chain relationship, where each ledger entry contains the hash value of its direct predecessor, with a jump step size S equal to 1. This structure ensures the basic continuity and immutability of the ledger, forming the first line of defense for data integrity. More crucially, the dashed arc arrows spanning multiple nodes represent jump pointers, one of the core innovations of this invention. As shown, these jump pointers are not randomly connected but follow strict mathematical rules; the jump step size S follows a sequence of powers of 2 minus 1, such as 3, 7, 15, etc.

[0087] For example, starting from node N, one dashed arc points to node N-3, with a corresponding jump step size of 3; another dashed arc points to the more distant node N-7, with a corresponding jump step size of 7. This topology logically forms a fast indexing mechanism similar to a skip list. During verification, this geometry allows the verification path to "skip" a large number of intermediate nodes. The diagram visually illustrates that to verify the integrity between node N and node N-7, the traditional blockchain structure requires seven hash operations to backtrack step by step, while the structure of this invention only needs a single jump to complete the link verification. This multi-level skip connection forms a logarithmic-level covering network on a macroscopic level, and its verification efficiency advantage will be amplified exponentially as the number of ledger entries increases. This topology diagram also metaphorically represents the anchoring depth of data. Node N, through multiple pointers of different spans, tightly holds onto historical data like an anchor. Any tampering with a historical entry (such as N-6) will not only break the adjacent solid line connection but also simultaneously break the long-distance dashed line connection spanning that node, thus causing the hash verification of multiple subsequent entries to fail. This highly redundant structural design greatly increases the computational cost and difficulty for attackers to forge the ledger. The diagram clearly illustrates how this structure achieves a dual improvement in verification efficiency and security without significantly increasing storage overhead.

[0088] The total number of existing ledger entries read by the billing server from the Merkle ledger is denoted as . , `value` is a non-negative integer representing the number of ledger entries currently written to the Merkle ledger. When... A value of 0 indicates that the Merkle ledger is empty, and the currently pending signed metering data packet is the first ledger entry. The billing server creates the first ledger entry, which contains the signed metering data packet, the current data hash value, and an empty set of jump pointers. Since there are no prior entries to the first ledger entry, its jump pointer set is empty.

[0089] when When the value is greater than 0, the billing server needs to construct a jump pointer set. The jump pointer set is a group of hash pointers pointing to existing ledger entries, each represented by the data hash value of the target entry. The jump step size of each pointer in the jump pointer set follows a specific mathematical rule, ensuring that starting from any entry, backtracking along the jump pointers can reach the beginning of the ledger in logarithmic steps.

[0090] The billing server calculates the jump step sequence, which contains five jump step values: 1, 3, 7, 15, and 31. The rule for generating the jump step sequence is: the jump step value in the sequence... The jump step size is equal to ,in It is a positive integer starting from 1. The value of the first jump step is... , indicating a reference to the direct predecessor entry; the second jump step value is , indicating a jump to an entry two entries apart; the third jump step value is This indicates a reference to an entry 6 entries apart; and so on. The jump step value is determined according to... The pattern of increasing values ​​allows the coverage of the jump pointer to expand exponentially, thus achieving logarithmic backtracking efficiency.

[0091] The jump step sequence contains 5 jump step values, meaning each ledger entry contains a maximum of 5 jump pointers. The number of jump pointers can be adjusted according to actual needs. Increasing the number of jump pointers can further reduce verification time complexity, but it will increase the storage overhead of each ledger entry. In the current design, each jump pointer occupies 32 bytes (256-bit hash value), and 5 jump pointers occupy a total of 160 bytes. Compared to the typical size of tens of kilobytes of signed metering data packets, the storage overhead of jump pointers is negligible.

[0092] The billing server checks each jump step value in the jump step sequence sequentially. For the currently checked jump step value ,like Greater than or equal to This indicates that there is an entry in the Merkle ledger that is separated from the currently pending entry. An existing entry for each entry, the sequence number of which is... The billing server reads the sequence number from the Merkle ledger. The current data hash value of the ledger entry, using that hash value as the first... Jump pointer hash value, and then the first The jump pointer hash value is added to the jump pointer set. If Less than If the jump step is not long enough, it means that there are no existing entries in the Merkle ledger that are far enough away to support the jump step. The billing server skips the processing of the jump step value and does not add the corresponding jump pointer to the jump pointer set.

[0093] After constructing the jump pointer set, the billing server calculates the entry anchor hash value. The entry anchor hash value is used to bind the current ledger entry to all existing entries pointed to by its jump pointers, forming a cryptographic association. Any tampering with existing entries will cause the entry anchor hash value verification to fail. The entry anchor hash value is calculated as follows: the current data hash value and all jump pointer hash values ​​in the jump pointer set are concatenated end-to-end in ascending order of jump step size to form a pointer concatenation string. The SHA-256 hash operation is then performed on this pointer concatenation string to obtain the entry anchor hash value.

[0094] Let the current data hash value be The jump pointer hash values ​​in the jump pointer set are arranged in ascending order of jump step size as follows: ,in This represents the actual number of jump pointers. This corresponds to the jump step size value. Pointer concatenation string. The construction method is as follows ,in This indicates a byte string concatenation operation. The entry is anchored to a hash value. Calculated as .

[0095] The billing server creation sequence number is The ledger entries, numbered as The ledger entry contains a signed metering packet, the current data hash, a set of jump pointers, and the entry anchor hash. The billing server will assign the sequence number... Ledger entries are appended to the Merkle ledger. Append-write operations are performed atomically, ensuring that ledger entries are either completely written or not written at all, thus avoiding data inconsistencies due to system failures.

[0096] In an optional implementation, the Merkle ledger can also employ a distributed storage architecture to improve availability and disaster recovery capabilities. Multiple storage nodes maintain a strongly consistent copy of the ledger data through the Raft consensus protocol, ensuring that the failure of any minority of nodes does not affect the normal operation of the system. Write operations require confirmation from a majority of nodes to be considered successfully committed, while read operations can be executed from any healthy node. The construction and verification logic of the jump pointer chain structure under the distributed storage architecture remains unchanged; only the underlying storage access interface is replaced with a distributed storage client.

[0097] The billing server constructs a Merkle tree based on the Merkle ledger and generates anchored credentials, which are then returned to the billing terminal. A Merkle tree is a binary hash tree data structure. Leaf nodes store the hash value of the original data, non-leaf nodes store the hash value of the concatenation of the hash values ​​of their two child nodes, and the hash value of the root node is called the Merkle root hash value. Merkle trees can generate compact proofs of data existence, proving that a data item is indeed contained in the tree; the proof size is only [missing information]. ,in This represents the number of leaf nodes.

[0098] The Merkle tree is constructed as follows: The anchor hash values ​​of all ledger entries are sequentially used as leaf nodes of the Merkle tree. The order of the leaf nodes corresponds to the sequence number of the ledger entries; the first leaf node corresponds to the anchor hash value of the first ledger entry, the second leaf node corresponds to the anchor hash value of the second ledger entry, and so on. Let the total number of leaf nodes be... The hash values ​​of each leaf node are denoted as follows: .

[0099] Starting from the first leaf node, each pair of adjacent leaf nodes forms a group. The anchor hash values ​​of the entries in the two leaf nodes within the same group are concatenated in order of leaf node number, and then a SHA-256 hash operation is performed to generate the hash value of the parent node in the same group. Let the first leaf node be... The leaf node and the first If all leaf nodes belong to the same group, their parent node hash values ​​are... Calculated as ,in It is a positive integer starting from 1.

[0100] If the total number of leaf nodes If the number of leaf nodes is odd, then the last leaf node is treated as a separate group. The hash value of the parent node of the group containing the last leaf node is equal to the anchor hash value of the entry of the last leaf node. ,in This indicates a rounding up operation. This approach allows the case of an odd number of leaf nodes to be integrated into the binary tree structure, with the last leaf node being directly promoted to the level of its parent node.

[0101] Repeat the above grouping and SHA-256 hashing process for all generated parent nodes. In each round of processing, the number of nodes at the current level is halved (rounded up if odd), aggregating upwards layer by layer until only one node remains. The hash value of this single remaining node is used as the Merkle root hash value. The Merkle root hash value is the cryptographic digest of the entire Merkle tree, uniquely identifying the complete state of the Merkle ledger at the current moment. Any modification to a ledger entry will cause a change in the Merkle root hash value.

[0102] In practice, the billing server does not need to completely rebuild the entire Merkle tree every time a new ledger entry is written. The billing server uses an incremental update strategy, recalculating only the hash values ​​of each level of nodes along the path from the newly added leaf node to the root node; the hash values ​​of the remaining nodes remain unchanged. Let the newly added leaf node be located at the... At each of the following locations, the Merkle tree has a height of [value]. Incremental updates only require computation The hash value of each node, with a time complexity of O(n). Far superior to a complete reconstruction .

[0103] The billing server generates an anchor credential and returns it to the billing terminal. The anchor credential is cryptographic evidence used by the billing terminal to subsequently verify that its signed metering data packet has been included in the Merkle ledger. The anchor credential includes the following components: the Merkle root hash value, the sequence number of the ledger entry, and the hash values ​​of all sibling nodes along the path from the leaf node corresponding to the ledger entry to the root node of the Merkle tree, as well as the left and right position markers of all sibling nodes.

[0104] A sibling node is another child node in a Merkle tree that shares the same parent node as the target node. On the path from a leaf node to the root node, there is one sibling node at each level (except the root level). The hash value of the sibling node is one of the necessary inputs for calculating the hash value of the parent node. Left and right position markers indicate the relative position of the sibling node to the target node: if the sibling node is to the left of the target node, its hash value should be concatenated before the target node's hash value when calculating the parent node's hash value; if the sibling node is to the right of the target node, the concatenation order is reversed.

[0105] Let the serial number of the ledger entry be... The height of the Merkle tree is The sibling node information in the anchored certificate is represented as a sequence. ,in For the first The hash value of the sibling node at the same level. Mark the left or right position of this sibling node ("left" or "right"). The total size of the anchored credentials is The data consists of 32 bytes (the Merkle root hash value), 4 bytes (the ledger entry sequence number), and 33 bytes (32 bytes of hash value plus 1 byte of position marker) for each sibling node. For a Merkle tree containing 1 million ledger entries... The anchored credential size is approximately 696 bytes.

[0106] After receiving the anchoring credential, the billing terminal stores it in its local non-volatile memory and associates it with the corresponding signed metering data packet. In the event of a billing dispute, the billing terminal can present the signed metering data packet and the anchoring credential. Any third party can verify that the metering data packet has been included in the billing server's Merkle ledger through the following verification process: First, recalculate the current data hash value of the signed metering data packet; then, recalculate the entry anchoring hash value according to the jump pointer structure of the ledger entry (requiring access to the Merkle ledger to obtain the data hash value of the existing entry pointed to by the jump pointer); next, starting from the entry anchoring hash value, concatenate it sequentially with the hash values ​​of each level of sibling nodes in the anchoring credential according to the left and right position markers and perform SHA-256 hash operation, calculating upwards layer by layer until the root node hash value is obtained; finally, compare the calculated root node hash value with the Merkle root hash value in the anchoring credential. If they match, the verification is successful.

[0107] At the end of the billing cycle, the billing server extracts a set of call records from the Merkle ledger to generate a billing invoice. A billing cycle refers to the time interval for billing, typically one calendar month in length. The billing server initiates the billing generation process on the first business day after the end of the billing cycle.

[0108] The billing server iterates through all ledger entries in the Merkle ledger whose end timestamps of the time window fall within the billing period. This iteration is accelerated by a timestamp index; the billing server maintains a secondary index with the end timestamp of the time window as the key, enabling rapid location of the set of ledger entries within a specified time range. From each ledger entry, a signed metering data packet is extracted, and then from the signed metering data packet, a set of call records is extracted.

[0109] The billing server categorizes and summarizes all extracted call records according to the API identifiers of the called APIs to generate billing details. The categorization and summarization process is as follows: First, a summary table is created with the API identifier of the called API as the key; then, each call record is traversed, and the corresponding entry in the summary table is located according to its API identifier, and the number of calls and the amount of data transmitted for that entry are accumulated; after the traversal is completed, the summary table records the total number of calls and the total amount of data transmitted for each called API within the billing period, which is the billing detail.

[0110] The billing server generates billing invoices based on preset billing rules. These rules define the unit price and billing method for each invoked API. Billing methods include billing by the number of calls, billing by data transfer volume, billing by duration, or a combination thereof. When billing by the number of calls, the API cost equals the number of calls multiplied by the unit price per call; when billing by data transfer volume, the API cost equals the data transfer volume multiplied by the unit price per byte; in mixed billing, the costs of each component are added together. The billing invoice summarizes the costs of all invoked APIs to obtain the total cost for the billing period, while also recording detailed information for user verification.

[0111] The generated billing invoices are stored in the billing server's billing database in a structured data format and simultaneously pushed to users via email or API interface. Billing data includes: billing cycle start and end times, user ID, number of API calls and data transfer volume, subtotal of charges for each API call, discount amount, total amount due, billing generation timestamp, and the billing server's digital signature. The digital signature ensures the integrity and authenticity of the billing content, preventing tampering during transmission.

[0112] The preferred embodiments of this disclosure have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of this disclosure. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of this disclosure shall be within the scope of the claims of this disclosure.

Claims

1. A general artificial intelligence application API proxy billing system, comprising a billing terminal and a billing server; the billing terminal has a built-in physical non-cloning function circuit and a physical non-cloning function circuit array, the billing terminal is used to send an authentication request to the billing server, input a random challenge value into the physical non-cloning function circuit to obtain a challenge response value, intercept general artificial intelligence application API call requests and extract call records, collect call records according to a preset time window to form a call record set, perform iterative folding signature processing based on the physical non-cloning function circuit array on the call record set to generate a folded signature value, and combine the call record set and the folded signature value to form a signed metering data packet; The billing server sends random challenge values ​​to the billing terminals and verifies the challenge response values ​​according to a pre-registered challenge response lookup table. It then verifies the signature of signed metering data packets. Upon successful verification, the signed metering data packets are written to a Merkle ledger using a skip pointer chain structure. A Merkle tree is constructed based on the Merkle ledger, and anchored credentials are generated and returned to the billing terminal. At the end of the billing cycle, the server extracts a set of call records from the Merkle ledger to generate a billing invoice. The data preprocessing process for iterative folding signature processing is as follows: all call records in the call record set are arranged in chronological order according to the call timestamps and concatenated end to end to form the original byte stream. Zero-value bytes are padded to the end of the original byte stream until the total length of the original byte stream is a multiple of 256 bits to form the padded byte stream. The padded byte stream is divided into data blocks of 256 bits each, forming data blocks 1 to K in sequence, where K is the quotient of the total number of bits in the padded byte stream divided by 256. The initialization process for iterative folding signature processing is as follows: a 256-bit status register is initialized. The initial value of the status register is the output value of the device identifier of the billing terminal after SHA-256 hash operation. Initialize the cell pointer, with an initial value of 1. The iterative execution process of the folded signature processing is as follows: starting from the first data block, process each data block sequentially. For the currently processed data block, read the current value of the status register as the first input value, input the first input value into the physical non-cloning function cell currently pointed to by the cell pointer to obtain the first response value, perform a bitwise XOR operation between the first response value and the currently processed data block to obtain the first intermediate value, increment the cell pointer by 1, and if the cell pointer value exceeds 16, reset the cell pointer value to 1, input the first intermediate value into the physical non-cloning function cell currently pointed to by the cell pointer to obtain the second response value, write the second response value into the status register to overwrite the original value in the status register, increment the cell pointer by 1, and if the cell pointer value exceeds 16, reset the cell pointer value to 1, and continue processing the next data block until the Kth data block is processed. After all data blocks are processed, read the final value of the status register as the folded signature value. The construction process of the jump pointer chain structure is as follows: perform a SHA-256 hash operation on the signed metering data packet to obtain the current number. Based on the hash value, the total number of existing ledger entries read from the Merkle ledger is denoted as N. When N equals 0, the first ledger entry is created, containing a signed metering data packet, the current data hash value, and an empty set of jump pointers. When N is greater than 0, the jump pointer set is constructed as follows: each jump step value in the jump step sequence is checked sequentially. The jump step sequence contains 1, 3, 7, 15, and 31. For the currently checked jump step value S, if N is greater than or equal to S, then the jump pointer is retrieved from the Merkle ledger. Read the current data hash value of the ledger entry with sequence number N-S+1 as the hash value of the S-th jump pointer and add it to the jump pointer set; concatenate the current data hash value with all the jump pointer hash values ​​in the jump pointer set in ascending order of jump step value to form a pointer concatenation string, perform SHA-256 hash operation on the pointer concatenation string to obtain the entry anchor hash value; create a ledger entry with sequence number N+1, which contains the signed metering data packet, the current data hash value, the jump pointer set, and the entry anchor hash value.

2. The system according to claim 1, characterized in that, The call record includes the call timestamp, caller identifier, called API identifier, and data transfer volume; the signed metering data packet also includes the start timestamp and end timestamp of the time window.

3. The system according to claim 1, characterized in that, The Physically Unclonable Function (PUC) circuit array contains 16 independent PUC units, which are arranged in a 4x4 matrix structure and numbered sequentially from unit 1 to unit 16. Each PUC unit accepts 256-bit input and produces 256-bit output.

4. The system according to claim 1, characterized in that, The Merkle tree construction process is as follows: The anchor hash values ​​of all ledger entries are sequentially used as leaf nodes of the Merkle tree. Starting from the first leaf node, every two adjacent leaf nodes are grouped together. The anchor hash values ​​of the two leaf nodes in the same group are concatenated in order of leaf node number and then subjected to SHA-256 hashing to generate the hash value of the parent node in the same group. If the total number of leaf nodes is odd, the last leaf node is grouped separately, and the hash value of the parent node of the last leaf node group is equal to the anchor hash value of the last leaf node. This grouping and SHA-256 hashing process is repeated for all generated parent nodes until only one node remains. The hash value of this last node is used as the Merkle root hash value.

5. The system according to claim 4, characterized in that, The anchoring credential includes the Merkle root hash, the sequence number of the ledger entry, and the hashes of all sibling nodes along the path from the leaf node corresponding to the ledger entry to the root node of the Merkle tree, as well as the left and right position markers of all sibling nodes.

6. A general artificial intelligence application API proxy billing method, characterized in that, Includes the following steps: Step 1, Billing Terminal Identity Authentication: The billing terminal sends an authentication request to the billing server, the billing server sends a random challenge value to the billing terminal, the billing terminal inputs the random challenge value into the physical non-cloning function circuit to obtain the challenge response value, and the billing server verifies the challenge response value according to the pre-registered challenge response lookup table; Step 2, Metering data signing: The billing terminal intercepts API call requests from general artificial intelligence applications and extracts call records. It collects call records according to a preset time window to form a call record set. It performs iterative folding signature processing based on a physically non-clonable function circuit array on the call record set to generate a folded signature value. The call record set and the folded signature value are combined to form a signed metering data packet. Step 3, Billing Data Anchoring: The billing server verifies the signature of the signed metering data packet. After successful verification, the signed metering data packet is written into the Merkle ledger, which uses a skip pointer chain structure. The Merkle tree is constructed based on the Merkle ledger, and anchoring credentials are generated and returned to the billing terminal. Step 4, Billing Bill Generation: At the end of the billing period, the billing server extracts the set of call records from the Merkle ledger, categorizes and summarizes them according to the API identifier of the call to generate billing details, and generates a billing bill according to the preset billing rules. The data preprocessing process of iterative folding signature processing is as follows: all call records in the call record set are arranged in chronological order according to the call timestamps and concatenated end to end to form an original byte stream. Zero-value bytes are padded to the end of the original byte stream until the total length of the original byte stream is a multiple of 256 bits to form a padded byte stream. The padded byte stream is divided into data blocks of 256 bits each, forming data blocks 1 to K in sequence, where K is the quotient of the total number of bits in the padded byte stream divided by 256. The initialization process of iterative folding signature processing is as follows: a 256-bit status register is initialized. The initial value of the status register is the output value of the device identifier of the billing terminal after SHA-256 hash operation. Initialize the cell pointer, with an initial value of 1. The iterative execution process of the folded signature processing is as follows: starting from the first data block, process each data block sequentially. For the currently processed data block, read the current value of the status register as the first input value, input the first input value into the physical non-cloning function cell currently pointed to by the cell pointer to obtain the first response value, perform a bitwise XOR operation between the first response value and the currently processed data block to obtain the first intermediate value, increment the cell pointer by 1, and if the cell pointer value exceeds 16, reset the cell pointer value to 1, input the first intermediate value into the physical non-cloning function cell currently pointed to by the cell pointer to obtain the second response value, write the second response value into the status register to overwrite the original value in the status register, increment the cell pointer by 1, and if the cell pointer value exceeds 16, reset the cell pointer value to 1, and continue processing the next data block until the Kth data block is processed. After all data blocks are processed, read the final value of the status register as the folded signature value. The construction process of the jump pointer chain structure is as follows: perform a SHA-256 hash operation on the signed metering data packet to obtain the current number. Based on the hash value, the total number of existing ledger entries read from the Merkle ledger is denoted as N. When N equals 0, the first ledger entry is created, containing a signed metering data packet, the current data hash value, and an empty set of jump pointers. When N is greater than 0, the jump pointer set is constructed as follows: each jump step value in the jump step sequence is checked sequentially. The jump step sequence contains 1, 3, 7, 15, and 31. For the currently checked jump step value S, if N is greater than or equal to S, then the jump pointer is retrieved from the Merkle ledger. Read the current data hash value of the ledger entry with sequence number N-S+1 as the hash value of the S-th jump pointer and add it to the jump pointer set; concatenate the current data hash value with all the jump pointer hash values ​​in the jump pointer set in ascending order of jump step value to form a pointer concatenation string, perform SHA-256 hash operation on the pointer concatenation string to obtain the entry anchor hash value; create a ledger entry with sequence number N+1, which contains the signed metering data packet, the current data hash value, the jump pointer set, and the entry anchor hash value.

Images