Timestamp Service - Revision history

Fireduck at 08:55, 9 March 2024

2024-03-09T08:55:42Z

2024-03-09T08:53:30Z

2024-03-09T08:52:44Z

‎API

2024-03-08T21:44:27Z

‎Design

2024-03-08T21:43:09Z

‎Scaling

2024-03-08T21:36:15Z

‎Uses

2024-03-08T21:32:59Z

‎Design

2024-03-08T21:31:08Z

‎Design

2024-03-08T21:22:07Z

‎Overview

2024-03-08T21:18:19Z

‎Version Plan

← Older revision		Revision as of 08:55, 9 March 2024
Line 35:		Line 35:

	[https://timestamp.snowblossom.org/api/v1/info Info]		[https://timestamp.snowblossom.org/api/v1/info Info]
		+	[https://timestamp.snowblossom.org/api/v1/publish?hash=c638dd867d7d49fc626e8aed0aef56c1b62da71ff43622d26c0b859e449dfc07 Publish]
		+	[https://timestamp.snowblossom.org/api/v1/getproof?transaction_hash=b21cd8220f6c900cdbeeac406b7d81c27f3ae11ea04f06f4599d2f867b91896a GetProof]

	== Design ==		== Design ==

@@ Line 32: / Line 32: @@
 == Instances ==
-We are running an instance that anyone is free to use at https://timestamp.snowblossom.org/
+We are running an instance that anyone is free to use at [https://timestamp.snowblossom.org/api/v1/info https://timestamp.snowblossom.org/]
 [https://timestamp.snowblossom.org/api/v1/info Info]

@@ Line 25: / Line 25: @@
 The API is simple.  One call that provides the data to include and the result is some transaction ID for the timestamp.
 Then some time later, the user can call again with the transaction ID and get the entire proof.
 == Design ==

@@ Line 362: / Line 362: @@
    "snow_transaction": "c3be5a72e6ab2d6fabf3eae673cf4e6491d551946b48a4b2270cf75fc4b4c2bb"
+  }
 == Version Plan ==

← Older revision		Revision as of 21:43, 8 March 2024
Line 370:		Line 370:

	== Scaling ==		== Scaling ==
		+
		+	For such a service to be really useful, it needs to scale and continue to be inexpensive.
		+
		+	Here is an example architecture that would work:
		+
		+	API endpoint goes to a request router. The request router knows which backends (each running their own channel) are availible.
		+	Request router sends timestamp requests to an available backend.
		+	Request router sends proof requests to the appropriate backend for the chain the transaction is on.
		+
		+	The backend nodes operate on channels each with an active-active configuration where any of the nodes on a channel could accept timestamp requests, service proof lookups or generate blocks. There would have to be a little coordination to avoid creating blocks close in time and confusing the channel's mempool. Same for deciding when to save state to the upstream timestamp service.
		+
		+	So imagine the backend nodes as pairs, each pair servicing one channel. Then the occasionally save state to an upstream timestamp service. Add more pairs running channels as needed for the load.
		+
		+	The upstream master timestamp service would occasionally save to public blockchains.
		+
		+	With this model, we can extend to a very high request rate while still only saving a transaction on a public chain every few blocks.

@@ Line 15: / Line 15: @@
 == Uses ==
 The cheap is super important.  Often, we probably won't know the value of data or having a proof on it until much later.
 == API ==

← Older revision		Revision as of 21:32, 8 March 2024
Line 40:		Line 40:

	Example proof, which proves that the data_hash of 710150e9eb6d7b7377e75d82f43bb4a84fc3ea42f08ea56bd594c4be7c4fb3b2 was included in Snowblossom Block [https://explorer.snowblossom.org/?search=0000000000276312f079297412ecd2168f9b21057dc911758984add713c551b8 0000000000276312f079297412ecd2168f9b21057dc911758984add713c551b8].		Example proof, which proves that the data_hash of 710150e9eb6d7b7377e75d82f43bb4a84fc3ea42f08ea56bd594c4be7c4fb3b2 was included in Snowblossom Block [https://explorer.snowblossom.org/?search=0000000000276312f079297412ecd2168f9b21057dc911758984add713c551b8 0000000000276312f079297412ecd2168f9b21057dc911758984add713c551b8].
		+
		+	The number of steps will depend on the depth of the merkle trees for timestamp data going into the channel block, the number of channel blocks until one that is included in the public blockchain and the merkle depth of transactions in the blockchain.

	{		{

@@ Line 12: / Line 12: @@
 However, this means making transactions on the public ledger, which are not cheap.  [https://en.wikipedia.org/wiki/Merkle_tree Merkle Trees] to the rescue.  We can take a bunch of data we want to timestamp, combine it all using a merkle tree and embed that single result in the blockchain.  That is the purpose of this project, to be able to make cheap blockchain based timestamps.
 == API ==
@@ Line 20: / Line 24: @@
 == Design ==
+This timestamp service uses [[Channels]] as the metadata storage layer.
 == Version Plan ==

@@ Line 24: / Line 24: @@
 == Version Plan ==
-* v1 - Basic operation backed by Snowblossom
+* v1 - Basic operation backed by Snowblossom (done as of 2024.03.04)
 * v2 - Recursive operation (a timestamp service can use another timestamp service as its backing)
 * v3 - Other chains (Bitcoin, Bitcoin Cash, Ethereum)
 == Scaling ==