SecLog, read closely: letting a delivery leave its own receipt

In one line: “the user cannot deny receiving the data” needs no trusted API and no data on chain — only a design where the last half of the decryption key can appear through one path, and that path leaves a record.

The paper is four pages long. What it asks for is small, too: after a query result is handed over, how do you make sure a record of it lands on chain? Small enough that your first reaction is “just write a log entry” — and then you follow the authors and find that every step of it runs into the same question. Who is trustworthy here?

The line I keep coming back to is this one: a blockchain guarantees that what got written cannot be changed. What this setting needs is that the entry that should be written gets written. Those are near-identical sentences pointing in opposite directions — one is about the past, the other about the future.

It is by Hughes, Hossain, Tang, Jung and Chenli, published at METAVERSE 2025 (LNCS 16159, pp. 115–124). Four pages, neatly built: the problem, then prior work sorted into two piles, then the model, the protocol and two theorems, then three contracts on a scale and an honest page about cost. I’ll walk the same order.

1. After you sign the consent form

Say your medical record sits in a hospital’s database. One day someone reads it. Research, insurance, something else — you cannot tell.

You did know about the moment you signed. What about afterwards? The paper puts it plainly: for most people the only thing they ever learn about the process is that first signature, when they agreed to let some entity share their data. Which records were read, when, and what was done with them never comes back to them. This is not a matter of polish. HIPAA, GDPR and CCPA all ask for traceability, and sharing without transparency is already standing on the wrong side of that line.

Decentralized databases — the paper points at recallnet’s list of them — give ownership and control back to the person the data came from, which solves the first half of the problem. And once ownership comes back, the second half shows up: nobody keeps the record.

That is where it gets harder than it sounds. Three obvious answers, and the paper closes all three. Ask the user to confirm receipt? Anyone planning to deny it simply won’t. Let the API write the log on its own? One network hiccup and the user genuinely got nothing, so the log is a lie — and the API becomes a single point of failure besides. Put the sharing events straight on a blockchain? The authors’ own words: that cannot guarantee the correctness and the completeness of the logging.

With those closed, the authors turn to a different field: fair exchange, where HTLC-style atomic swaps have long bound “access to the data” and “payment” into one all-or-nothing step.

SecLog’s whole trick sits in one move: swap the payment for the record, and atomicity survives. Because in this setting the user never pays the API for the data anyway; what needs to be bound together is the data arriving and an event happening.

The paper lists four contributions, modestly: a protocol that enforces a record whenever a sharing succeeds in a decentralized setting; a security proof; a simulation showing less gas than payment-based atomic swaps; and open code at github.com/avocado-avery/SecLog.

2. Two research lines, each with the same corner missing

The second part sorts prior work into two piles, and they map onto the two columns of the figure below. What is striking is that both piles are solid work and both miss the same corner.

Start with the blockchain logging pile. Gao encrypts audit logs homomorphically — confidentiality up, at the cost of shutting users out of verifying their own inclusion. Cha’s IoT auditing system leans on trusted infrastructure. Zhao and López-Pimentel put Merkle hashes and roots on chain, which handles tamper evidence, though the detail stays off chain and its availability is an assumption. Hsu pairs blockchain with access control for IoT storage; Cha and Hasan put cloud logs inside a trusted execution environment. AuditChain, BlockAuditor and LogChain go further, and the paper is blunt about what remains: they still assume the participants running the infrastructure are honest, and they do not address omission — the event that is quietly left out, with nobody able to notice.

The authors’ one-line summary of that whole line is the gap they aim at: there is no mechanism that lets users independently confirm that their action was actually logged. SecLog’s placement is to fold verification into the act of logging itself — verifiable inclusion and censorship resistance without a trusted logger, storage node or any single participant.

The other pile is fair exchange. FairSwap, OptiSwap and Universal Atomic Swaps build clean atomicity out of contracts and cryptographic primitives; Zhu and Tas push it into private-key exchange and zero-knowledge proofs. The issue with them is not quality but scope: they are all built for a single-shot trade, coins for a file. In the paper’s phrasing, those models do not support persistent, auditable event streams. “Log every query” was never their problem to solve.

Underneath both lines sits the system SecLog is bolted onto: Web3DB, a decentralized relational database that answers SQL, built from four layers — data injection, access control, database engine, and storage on IPFS.

A query goes to the SQL API. The API asks the access-control layer to check credentials and rewrite the query against the ACL, passes it to the engine layer, where a randomly selected master node coordinates the slaves, then takes the result and hands it back to the user.

Watch that last hop. This is where the paper points at the screw it wants to loosen: underneath the whole flow sits an assumption that the user is honest, and will not deny receiving the results. That holds on a hospital LAN. It does not hold on the Internet.

3. The authors keep the frame small: three roles, two definitions, three assumptions

Part three narrows the scope first: three kinds of entity. Users send queries and wait. The API receives, collects and returns. Blockchain nodes validate transactions and execute contracts. Node misbehaviour is explicitly out of scope — that belongs to consensus research, not here.

Then two definitions, one line each:

• Correctness — every sharing record on chain corresponds to a sharing that actually finished: the API sent the result, the user received it.
• Completeness — every successful retrieval leaves a corresponding record on chain.

Those two sentences are the entire target. Three assumptions hold them up, and they deserve a slow read, because the weight of the two theorems lives here.

First, the chain is secure and not selectively censoring: no 51% attack, no collusion to block a particular transaction — the user’s deployment, the API’s call — so liveness is guaranteed, and a user who gets online once after the API’s response is confirmed will eventually hold the data. Second, payloads travel encrypted; otherwise the data is either readable by every node or the querier can deny having received it. Third, the API crashes but does not lie: crash faults only, no Byzantine behaviour, and a malicious data provider is out of scope — data correctness belongs to the Fair²Trade line.

4. Four steps, one point, two events

The design section is short. Follow the figure and it is four steps.

The API takes the result, encrypts it with its own key sk, and splits sk at random into two halves, sk = sk1 + sk2. Both steps are off chain and cost nothing.

Then it sends sk1 and the ciphertext to the user. At that moment sk1 is known to exactly two parties: the API and the user.

Now comes the small move the whole paper turns on. The user derives a condition value from sk1 and deploys a contract that carries it. With the paper’s ElGamal example the public key is pk = g^sk, so

1cond = pk / g^sk1 = g^sk / g^sk1 = g^(sk − sk1) = g^sk2

cond is a commitment: whoever can produce sk2 proves they hold the other half. The contract is a variant HTLC, and it only fires the receipt event when ecMul(sk2, G) == cond. Nothing to produce, no event, and the contract lapses at its expiry.

Last step: the API looks at the contract and checks that cond is the point it expects. If it is, it calls the contract with sk2 and the event fires. If it isn’t, the API simply ignores the contract.

None of the input verification is new. The authors say so directly — it follows Fair²Trade’s construction, and the contribution here is enforcement rather than the primitive, so the details stay in the earlier paper.

The contract is 4.2 KB, and there is a naming trap worth knowing before you read it: the fields are called sk1x / sk1y, but what they hold is the point g^sk2 — the user’s commitment — not sk1.

1// contracts/SecLog.sol: sklockMatches is the whole paper's atomicity
2(sk2x, sk2y) = EllipticCurve.ecMul(sk2, GX, GY, AA, PP);      // sk2 * G
3require(logs[_logId].sk1x == sk2x, "sk2 does not match");     // compare with the user's point
4require(logs[_logId].sk1y == sk2y, "sk2 does not match");

1// contracts/SecLog.sol: only the receiver (the API) may trigger it, and only once
2require(log.receiver == msg.sender, "Only receiver can verify");
3require(keccak256(_message) == log.messageHash, "Message hash mismatch");
4log.verified = true;
5emit LogVerified(_logId);

The skeleton of the paper is two events.

LogEntryNew fires when the user deploys, carrying the logId, both addresses, the commitment point, the message hash and the timelock — it proves intent. LogVerified fires when the API’s call succeeds, and only when the point and the hash both match — it proves fact, and it writes sk2 permanently into calldata.

5. Two theorems, one paragraph of proof each

The security section is short by design.

Theorem 1, correctness. The design guarantees correctness as long as the user can reach the blockchain at least once after the API’s response is confirmed. The proof is straightforward: with a working connection the user recovers sk as soon as the API supplies the right sk2. The awkward case is the user who is offline and misses chain updates — but by the earlier assumption the chain is live, so one connection and one update are enough to read sk2.

Theorem 2, completeness. The design guarantees completeness as long as the API provides a valid input to a valid contract the user deployed. Same reasoning: by the atomic property of the HTLC, a correct input is validated by the nodes and executes the event, so a correctly deployed contract always produces the record.

Both hold, and both are short. It took me a second pass to notice what makes them short: they name what the model already granted. The work is not in the proofs, it is in those three assumptions — liveness, encryption, and an API that does not lie.

Which is why I would not describe this paper as eliminating trust. It relocates it: from trusting one API to trusting an entire chain. That distinction matters, because it decides who pays the bill.

6. Three contracts, one chart, and where my rerun disagrees

The evaluation setup is plain: Ethereum contracts, Truffle with a local Ganache chain, Solidity 0.5.0, gas read straight out of Ganache logs and the Truffle console. Three contracts.

SecLog.sol is the proposal. Fair2Trade.sol is the payment-based baseline — in Fair²Trade the data buyer sets up an HTLC and the broker redeems the deposit by handing over access. The third, CIDLog.sol, is a naive baseline the authors wrote themselves: don’t encrypt, dump the result on IPFS, and use the result’s CID as the sk in the HTLC.

The headline is that SecLog costs about 8,000 gas less than Fair²Trade. The reason is mundane: Fair²Trade actually launches a deposit transfer once the broker supplies a valid sk2, while SecLog only fires a “valid input received” event. The gap is smaller than an ETH transfer’s 21,000 gas because SecLog’s extra confirmation step costs something too. CIDLog lands on exactly the same gas as SecLog — a CID is 32 bytes like sk, so verification costs the same — but a CIDLog user cannot download anything until the swap completes, and the design drags in one more entity and a harder verification problem.

I put the same bytecode on a local EVM (solc 0.5.17, py-evm on the Istanbul and London forks). Half of it reproduced. Half did not.

The half that reproduced is rather satisfying: Fair2Trade − SecLog comes out at 8,038 gas on London and 8,026 on Istanbul. The paper’s prose says 8,000; the authors’ chart data says 8,166 (696,991 minus 688,825). Within 1.6%.

The half that did not is the eye-catching one: Fig. 2 reports 688,825 gas, and the same bytecode costs 186,415 here — 3.7 times apart. My first suspect was the EVM fork, since the Berlin modexp repricing is large and this curve library does modular inversion through modexp. Istanbul gives 179,327, though, still nowhere near, so that theory dies.

So I would rather read this as a reminder than as a correction. A four-page paper measured on Truffle plus Ganache is a different stack; gas absolutes do not travel between papers, the delta and the order of magnitude do.

The paper also leaves an anchor anyone can recompute: per Etherscan’s gas tracker on 2025-07-26, one execution costs about $0.75. At that same rate, my 186,415 gas is about $0.20, and the user’s deployment — 1,164,022 gas — is about $1.27.

7. The discussion page is more honest than the body

§4.2 is the section I would hand to anyone who thinks this is a free lunch. Three added costs, no varnish.

First, network burden: users have to talk to a chain to receive the API’s input, which raises the bar on their connectivity, and the sync frequency depends on which chain — Bitcoin blocks are about 10 minutes, Ethereum’s about 12 seconds. Second, chain maintenance: liveness is an assumption, and the cost of keeping a chain alive is not in the protocol’s ledger; pick a different chain and it moves. Third, off-chain work: encryption, decryption, key splitting. The paper’s magnitudes are AES under 10 ms on a 1 MB payload and key splitting under 1 ms — next to the on-chain cost, noise.

Put those next to section 6’s gas and the picture sharpens:

One sentence: cryptography is nearly free next to consensus. The money in this protocol does not go to the elliptic curve, it goes to waiting for a block and paying for one. “8,000 gas cheaper than the payment-based swap” is true, and it is one small cell of a bill whose first line is a 1.16-million-gas deployment.

Draw the scope as a matrix and the boundary becomes easy to hold onto: the first two rows are genuinely closed, the last three are explicitly out of scope or taken as assumptions.

8. Every number, with where it came from

9. Three things you can check, and two I won’t pretend to know

Three commands, all against public data, no chain needed.

 1# 1. where the atomicity actually lives
 2curl -s https://raw.githubusercontent.com/avocado-avery/SecLog/main/contracts/SecLog.sol \
 3  | grep -n "ecMul\|keccak256(_message)\|emit LogVerified"
 4
 5# 2. is the query public? look at verifyLog's parameters
 6curl -s https://raw.githubusercontent.com/avocado-avery/SecLog/main/contracts/SecLog.sol \
 7  | grep -n "function verifyLog" -A 3
 8
 9# 3. cost: back out the implied gas price from "688,825 gas ≈ $0.75", then price my rerun
10python3 -c "p=0.75/688825; print(round(p*1e9,3),'gwei-equivalent'); print('186,415 gas ->', round(186415*p,2), 'USD')"

The second one is worth actually running. verifyLog(logId, sk2, message) needs message in the clear, otherwise keccak256(_message) cannot match messageHash. Which means the design assumes the query is published alongside the record. If you want privacy as well, you have to replace messageHash with a commitment — a hash of a hash — and then the contract can no longer check the content. It is a fork in the road, and the paper does not take it.

Two questions I cannot answer.

One is who pays. The paper compares only the verification step. Total the exchange and the user fronts 1.16M gas to deploy while the API pays 186k to verify; the naive “API writes one log entry” needs a single SSTORE and one event. What the 8,000 gas buys is not trusting the API. In how many settings is that worth a million gas? The paper doesn’t say.

The other is aggregation. One transaction per query means 10,000 transactions for 10,000 queries. The authors’ other Fair²Trade line amortises with epochs and Merkle roots — their Chart.ipynb is literally about it — and SecLog does not. Swap the single curve commitment for a Merkle tree: does atomicity survive?

That second one looks like the obvious next paper.

References

• Hughes, A., Hossain, S., Tang, W., Jung, T., Chenli, C.: SecLog: Atomic-Swap Based Secure Logging for Decentralized Data Sharing. METAVERSE 2025, LNCS 16159, pp. 115–124, Springer, 2026. doi:10.1007/978-3-032-06323-6_9
• Code: github.com/avocado-avery/SecLog (SecLog.sol, CIDLog.sol, FT.sol, EllipticCurve.sol)
• Chenli, C., Tang, W., Lee, H., Jung, T.: Fair²Trade: Digital Trading Platform Ensuring Exchange and Distribution Fairness. IEEE TDSC 21(5), 4827–4842, 2024.
• Mukherjee, S. S., et al.: Web3DB: Web 3.0 RDBMS for Individual Data Ownership. arXiv:2504.02713
• Dziembowski, S., Eckey, L., Faust, S.: FairSwap: How to Fairly Exchange Digital Goods. CCS 2018.
• Eckey, L., Faust, S., Schlosser, B.: OptiSwap: Fast Optimistic Fair Exchange. ASIA CCS 2020.
• Thyagarajan, S. A. K., Malavolta, G., Moreno-Sanchez, P.: Universal Atomic Swaps. IEEE S&P 2022.
• Tas, E. N., et al.: Atomic and Fair Data Exchange via Blockchain. CCS 2024.
• Zhu, Z., Zhang, R., Tao, Y.: Atomic Cross-Chain Swap Based on Private Key Exchange. Cybersecurity 7(1), 2024.
• Vishnia, G., Peters, G. W.: AuditChain: A Trading Audit Platform over Blockchain. Frontiers in Blockchain 3, 2020.
• Pourmajidi, W., Miranskyy, A.: LogChain: Blockchain-Assisted Log Storage. arXiv:1805.08868.
• Tang, W., Chenli, C., Ju, C., Jung, T.: Trac2Chain: Trackability and Traceability of Graph Data in Blockchain with Linkage Privacy. ACM/SIGAPP SAC 2022.
• Zhao, W., et al.: A Blockchain-Facilitated Secure Sensing Data Processing and Logging System. IEEE Access 11, 2023.
• Lopez-Pimentel, J. C., Morales-Rosales, L. A., Monroy, R.: RootLogChain: Registering Log-Events in a Blockchain for Audit Issues. Sensors 21(22), 7669, 2021.
• Ethereum docs: the 21,000-gas baseline for an ETH transfer, ethereum.org/en/developers/docs/gas
• Funding: NASA ULI (80NSSC23M0058) and NSF (OAC-2312973), per the paper’s acknowledgments.

• Previous
  Why Go Is the Default Language of the Agent Era
• Next
  Think Before You Act: How JevAct Gates LLM Agent Actions