@optimystic/db-core 0.29.0 → 1.0.0-beta.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
import type { RepoMessage } from "../network/repo-protocol.js";
|
|
2
|
+
import type { PendResult } from "../network/struct.js";
|
|
2
3
|
/**
|
|
3
4
|
* One member's vote on a cluster transaction, in either the promise or the commit map.
|
|
4
5
|
*
|
|
@@ -49,6 +50,16 @@ export type ClusterPeers = {
|
|
|
49
50
|
publicKey: string;
|
|
50
51
|
};
|
|
51
52
|
};
|
|
53
|
+
/**
|
|
54
|
+
* One member's own report of what its storage did with this transaction at consensus-apply time; see
|
|
55
|
+
* {@link ClusterRecord.applyOutcomes} for the trust rules. Only the pend arm exists today — a commit
|
|
56
|
+
* refusal is not reported this way, because a commit that reached commit-consensus is authoritative
|
|
57
|
+
* (the coordinator's own retained verdict plus the commit-promise guard cover that tier instead).
|
|
58
|
+
*/
|
|
59
|
+
export type MemberApplyOutcome = {
|
|
60
|
+
/** This member's storage refused the record's pend with a conflict-shaped result. */
|
|
61
|
+
pend?: PendResult;
|
|
62
|
+
};
|
|
52
63
|
export type ClusterRecord = {
|
|
53
64
|
messageHash: string;
|
|
54
65
|
peers: ClusterPeers;
|
|
@@ -84,6 +95,38 @@ export type ClusterRecord = {
|
|
|
84
95
|
networkSizeHint?: number;
|
|
85
96
|
/** Confidence in the network size estimate (0-1) */
|
|
86
97
|
networkSizeConfidence?: number;
|
|
98
|
+
/**
|
|
99
|
+
* What each member's OWN storage answered when it applied this record's operations at consensus,
|
|
100
|
+
* keyed by peer id. Advisory and **unsigned** — no hash covers it — and deliberately so: it is
|
|
101
|
+
* written by a member *after* the votes are cast, on the response it hands back, so no signed
|
|
102
|
+
* payload could carry it without a further round trip.
|
|
103
|
+
*
|
|
104
|
+
* Members set only their own entry, and only for a *conflict-shaped* pend refusal (one carrying
|
|
105
|
+
* `pending` or `missing`, per `isConflictFailure`) — the optimistic-concurrency verdict that a
|
|
106
|
+
* rival holds the blocks or already took the revision. Successes and bare-reason faults are
|
|
107
|
+
* omitted: a bare fault stays tolerated local divergence, mirroring the coordinator's own
|
|
108
|
+
* local-verdict arm.
|
|
109
|
+
*
|
|
110
|
+
* Why unsigned is acceptable: a hostile entry can only *downgrade* a reported pend success into a
|
|
111
|
+
* retryable conflict, which the writer answers by rebasing and trying again. The same member
|
|
112
|
+
* could already force strictly worse outcomes with a signed reject or conflict vote, so this adds
|
|
113
|
+
* no attack surface beyond retry pressure — and failing toward retry is the correct direction for
|
|
114
|
+
* optimistic concurrency. Never treat an entry here as evidence of anything but "retry".
|
|
115
|
+
*
|
|
116
|
+
* Old peers never set it and old coordinators ignore it, so it is wire-compatible in both
|
|
117
|
+
* directions.
|
|
118
|
+
*
|
|
119
|
+
* NOTE: unlike a signed reject/conflict vote, an entry here is unattributable — nothing verifies
|
|
120
|
+
* it came from the peer it is keyed under beyond the coordinator taking each peer's entry from
|
|
121
|
+
* that peer's own response, and no reputation penalty can be pinned on a false one. Fine while the
|
|
122
|
+
* worst it buys is retry pressure a signed vote could already produce. If a member is ever
|
|
123
|
+
* observed reporting refusals it did not make — writes on a block failing their retry budget with
|
|
124
|
+
* `coordinator-repo:pend-remote-refusal` naming one peer over and over — the fix is to make the
|
|
125
|
+
* entry attributable (sign it on a follow-up round) rather than to start trusting it less.
|
|
126
|
+
*/
|
|
127
|
+
applyOutcomes?: {
|
|
128
|
+
[peerId: string]: MemberApplyOutcome;
|
|
129
|
+
};
|
|
87
130
|
/** Transaction proceeded despite minority rejections */
|
|
88
131
|
disputed?: boolean;
|
|
89
132
|
/** Evidence of the dispute: which peers rejected and why */
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"structs.d.ts","sourceRoot":"","sources":["../../../src/cluster/structs.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAC;
|
|
1
|
+
{"version":3,"file":"structs.d.ts","sourceRoot":"","sources":["../../../src/cluster/structs.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,6BAA6B,CAAC;AAC/D,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,sBAAsB,CAAC;AAEvD;;;;;;;GAOG;AACH,MAAM,MAAM,SAAS,GAClB;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,SAAS,EAAE,MAAM,CAAA;CAAE,GACtC;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,YAAY,CAAC,EAAE,MAAM,CAAA;CAAE;AAC9D;;;;;GAKG;GACD;IAAE,IAAI,EAAE,UAAU,CAAC;IAAC,SAAS,EAAE,MAAM,CAAC;IAAC,YAAY,EAAE,MAAM,CAAA;CAAE,CAAC;AAEjE;;;;;;;;;;;;GAYG;AACH,wBAAgB,yBAAyB,CAAC,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,SAAS,CAAC,MAAM,CAAC,EAAE,KAAK,CAAC,EAAE,MAAM,GAAG,UAAU,CAE3G;AAED,8GAA8G;AAC9G,wBAAgB,8BAA8B,CAAC,IAAI,EAAE,MAAM,EAAE,SAAS,EAAE,SAAS,GAAG,UAAU,CAM7F;AAED,MAAM,MAAM,YAAY,GAAG;IAC1B,CAAC,EAAE,EAAE,MAAM,GAAG;QACb,UAAU,EAAE,MAAM,EAAE,CAAC;QACrB,wDAAwD;QACxD,SAAS,EAAE,MAAM,CAAC;KAClB,CAAC;CACF,CAAC;AAEF;;;;;GAKG;AACH,MAAM,MAAM,kBAAkB,GAAG;IAChC,qFAAqF;IACrF,IAAI,CAAC,EAAE,UAAU,CAAC;CAClB,CAAC;AAEF,MAAM,MAAM,aAAa,GAAG;IAC3B,WAAW,EAAE,MAAM,CAAC;IACpB,KAAK,EAAE,YAAY,CAAC;IACpB;;;;;;OAMG;IACH,iBAAiB,CAAC,EAAE,CAAC,GAAG,CAAC,CAAC;IAC1B,0GAA0G;IAC1G,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B;;;;;;;OAOG;IACH,OAAO,EAAE,WAAW,CAAC;IACrB,QAAQ,EAAE;QAAE,CAAC,MAAM,EAAE,MAAM,GAAG,SAAS,CAAA;KAAE,CAAC;IAC1C,OAAO,EAAE;QAAE,CAAC,MAAM,EAAE,MAAM,GAAG,SAAS,CAAA;KAAE,CAAC;IACzC,8FAA8F;IAC9F,oBAAoB,CAAC,EAAE,MAAM,CAAC;IAC9B,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,6CAA6C;IAC7C,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,oDAAoD;IACpD,qBAAqB,CAAC,EAAE,MAAM,CAAC;IAC/B;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA4BG;IACH,aAAa,CAAC,EAAE;QAAE,CAAC,MAAM,EAAE,MAAM,GAAG,kBAAkB,CAAA;KAAE,CAAC;IACzD,wDAAwD;IACxD,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,4DAA4D;IAC5D,eAAe,CAAC,EAAE;QACjB,cAAc,EAAE,MAAM,EAAE,CAAC;QACzB,aAAa,EAAE;YAAE,CAAC,MAAM,EAAE,MAAM,GAAG,MAAM,CAAA;SAAE,CAAC;KAC5C,CAAC;CACF,CAAA;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,gCAAgC,OAAO,CAAC;AAErD,MAAM,WAAW,sBAAsB;IACtC,4GAA4G;IAC5G,sBAAsB,EAAE,MAAM,CAAC;IAC/B,kEAAkE;IAClE,uBAAuB,EAAE,MAAM,CAAC;IAChC,gDAAgD;IAChD,sBAAsB,EAAE,MAAM,CAAC;IAC/B,qEAAqE;IACrE,oBAAoB,EAAE,OAAO,CAAC;IAC9B,0EAA0E;IAC1E,oBAAoB,EAAE,MAAM,CAAC;IAC7B;;;;;OAKG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;;;;;;OASG;IACH,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B;;;;;OAKG;IACH,2BAA2B,CAAC,EAAE,MAAM,CAAC;IACrC,6EAA6E;IAC7E,wBAAwB,EAAE,MAAM,CAAC;IACjC,yDAAyD;IACzD,cAAc,CAAC,EAAE,OAAO,CAAC;IACzB,sEAAsE;IACtE,2BAA2B,CAAC,EAAE,MAAM,CAAC;IACrC;;;;OAIG;IACH,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB;;;;;OAKG;IACH,sBAAsB,CAAC,EAAE,MAAM,CAAC;IAChC,sFAAsF;IACtF,6BAA6B,CAAC,EAAE,MAAM,CAAC;IACvC,wEAAwE;IACxE,iCAAiC,CAAC,EAAE,MAAM,CAAC;IAC3C,sDAAsD;IACtD,iCAAiC,CAAC,EAAE,MAAM,CAAC;IAC3C,gEAAgE;IAChE,+BAA+B,CAAC,EAAE,MAAM,CAAC;IACzC,iFAAiF;IACjF,+BAA+B,CAAC,EAAE,MAAM,CAAC;IACzC;;;;;;;OAOG;IACH,uBAAuB,CAAC,EAAE,MAAM,CAAC;IACjC,gLAAgL;IAChL,cAAc,CAAC,EAAE,KAAK,GAAG,MAAM,GAAG,UAAU,CAAC;IAC7C,4GAA4G;IAC5G,kBAAkB,CAAC,EAAE,MAAM,CAAC;IAC5B,gIAAgI;IAChI,oBAAoB,CAAC,EAAE,MAAM,CAAC;IAC9B;;;;;OAKG;IACH,4BAA4B,CAAC,EAAE,OAAO,CAAC;IACvC;;;OAGG;IACH,uBAAuB,CAAC,EAAE,uBAAuB,CAAC;CAClD;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,MAAM,uBAAuB,GAAG,QAAQ,GAAG,QAAQ,CAAC"}
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"structs.js","sourceRoot":"","sources":["../../../src/cluster/structs.ts"],"names":[],"mappings":"
|
|
1
|
+
{"version":3,"file":"structs.js","sourceRoot":"","sources":["../../../src/cluster/structs.ts"],"names":[],"mappings":"AAsBA;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,yBAAyB,CAAC,IAAY,EAAE,IAAuB,EAAE,KAAc;IAC9F,OAAO,IAAI,WAAW,EAAE,CAAC,MAAM,CAAC,IAAI,GAAG,GAAG,GAAG,IAAI,GAAG,CAAC,KAAK,CAAC,CAAC,CAAC,GAAG,GAAG,KAAK,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC;AACjF,CAAC;AAED,8GAA8G;AAC9G,MAAM,UAAU,8BAA8B,CAAC,IAAY,EAAE,SAAoB;IAChF,QAAQ,SAAS,CAAC,IAAI,EAAE,CAAC;QACxB,KAAK,QAAQ,CAAC,CAAC,OAAO,yBAAyB,CAAC,IAAI,EAAE,QAAQ,EAAE,SAAS,CAAC,YAAY,CAAC,CAAC;QACxF,KAAK,UAAU,CAAC,CAAC,OAAO,yBAAyB,CAAC,IAAI,EAAE,UAAU,EAAE,SAAS,CAAC,YAAY,CAAC,CAAC;QAC5F,OAAO,CAAC,CAAC,OAAO,yBAAyB,CAAC,IAAI,EAAE,SAAS,CAAC,IAAI,CAAC,CAAC;IACjE,CAAC;AACF,CAAC;AA2FD;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,gCAAgC,GAAG,IAAI,CAAC"}
|
package/package.json
CHANGED
package/src/cluster/structs.ts
CHANGED
|
@@ -1,4 +1,5 @@
|
|
|
1
1
|
import type { RepoMessage } from "../network/repo-protocol.js";
|
|
2
|
+
import type { PendResult } from "../network/struct.js";
|
|
2
3
|
|
|
3
4
|
/**
|
|
4
5
|
* One member's vote on a cluster transaction, in either the promise or the commit map.
|
|
@@ -53,6 +54,17 @@ export type ClusterPeers = {
|
|
|
53
54
|
};
|
|
54
55
|
};
|
|
55
56
|
|
|
57
|
+
/**
|
|
58
|
+
* One member's own report of what its storage did with this transaction at consensus-apply time; see
|
|
59
|
+
* {@link ClusterRecord.applyOutcomes} for the trust rules. Only the pend arm exists today — a commit
|
|
60
|
+
* refusal is not reported this way, because a commit that reached commit-consensus is authoritative
|
|
61
|
+
* (the coordinator's own retained verdict plus the commit-promise guard cover that tier instead).
|
|
62
|
+
*/
|
|
63
|
+
export type MemberApplyOutcome = {
|
|
64
|
+
/** This member's storage refused the record's pend with a conflict-shaped result. */
|
|
65
|
+
pend?: PendResult;
|
|
66
|
+
};
|
|
67
|
+
|
|
56
68
|
export type ClusterRecord = {
|
|
57
69
|
messageHash: string; // Serves as a unique identifier for the clustered transaction record
|
|
58
70
|
peers: ClusterPeers;
|
|
@@ -84,6 +96,36 @@ export type ClusterRecord = {
|
|
|
84
96
|
networkSizeHint?: number;
|
|
85
97
|
/** Confidence in the network size estimate (0-1) */
|
|
86
98
|
networkSizeConfidence?: number;
|
|
99
|
+
/**
|
|
100
|
+
* What each member's OWN storage answered when it applied this record's operations at consensus,
|
|
101
|
+
* keyed by peer id. Advisory and **unsigned** — no hash covers it — and deliberately so: it is
|
|
102
|
+
* written by a member *after* the votes are cast, on the response it hands back, so no signed
|
|
103
|
+
* payload could carry it without a further round trip.
|
|
104
|
+
*
|
|
105
|
+
* Members set only their own entry, and only for a *conflict-shaped* pend refusal (one carrying
|
|
106
|
+
* `pending` or `missing`, per `isConflictFailure`) — the optimistic-concurrency verdict that a
|
|
107
|
+
* rival holds the blocks or already took the revision. Successes and bare-reason faults are
|
|
108
|
+
* omitted: a bare fault stays tolerated local divergence, mirroring the coordinator's own
|
|
109
|
+
* local-verdict arm.
|
|
110
|
+
*
|
|
111
|
+
* Why unsigned is acceptable: a hostile entry can only *downgrade* a reported pend success into a
|
|
112
|
+
* retryable conflict, which the writer answers by rebasing and trying again. The same member
|
|
113
|
+
* could already force strictly worse outcomes with a signed reject or conflict vote, so this adds
|
|
114
|
+
* no attack surface beyond retry pressure — and failing toward retry is the correct direction for
|
|
115
|
+
* optimistic concurrency. Never treat an entry here as evidence of anything but "retry".
|
|
116
|
+
*
|
|
117
|
+
* Old peers never set it and old coordinators ignore it, so it is wire-compatible in both
|
|
118
|
+
* directions.
|
|
119
|
+
*
|
|
120
|
+
* NOTE: unlike a signed reject/conflict vote, an entry here is unattributable — nothing verifies
|
|
121
|
+
* it came from the peer it is keyed under beyond the coordinator taking each peer's entry from
|
|
122
|
+
* that peer's own response, and no reputation penalty can be pinned on a false one. Fine while the
|
|
123
|
+
* worst it buys is retry pressure a signed vote could already produce. If a member is ever
|
|
124
|
+
* observed reporting refusals it did not make — writes on a block failing their retry budget with
|
|
125
|
+
* `coordinator-repo:pend-remote-refusal` naming one peer over and over — the fix is to make the
|
|
126
|
+
* entry attributable (sign it on a follow-up round) rather than to start trusting it less.
|
|
127
|
+
*/
|
|
128
|
+
applyOutcomes?: { [peerId: string]: MemberApplyOutcome };
|
|
87
129
|
/** Transaction proceeded despite minority rejections */
|
|
88
130
|
disputed?: boolean;
|
|
89
131
|
/** Evidence of the dispute: which peers rejected and why */
|