Proto commits in hyperledger-labs/fabric-smart-client

These 26 commits are when the Protocol Buffers files have changed:

2026-11-05

feat(fabric)!: exchange and store transactions as platform messages (#2508) FSC sent transactions to other nodes and stored them as JSON of its own Go struct, which drops unknown fields silently and repeats what Fabric's messages already carry. At version 2 of the fabric and fabricx formats, negotiated per session (#2474), a transaction travels as a protobuf TransactionEnvelope and an endorsement response as a protobuf EndorsementResponse; at version 1 the bytes are the JSON v0.27 sends, and every node reads both forms. fabric and fabricx publish {1, 2}. The envelope (platform/fabric/protos, fsc.fabric.v1) carries the platform as its driver name, the routing key of #2443, the channel and an opaque payload. Fabric's payload holds the signed proposal and proposal responses as marshaled messages that keep the signed bytes and signatures byte for byte, the transient map, the fields of an unsigned transaction and the RWSet; Fabric-x's (platform/fabricx/protos, fsc.fabricx.v1) wraps it. A registry maps a driver name to its payload conversion, negotiation component and txID rule. Fabric's format is built in and Fabric-x registers its own, so platform/fabric does not depend on platform/fabricx; a test checks this, and endorser.ValidateReceived asks the registry instead of naming the Fabric-x driver. Conversion refuses JSON with fields it cannot carry or without a txID. Transaction.Bytes() stays JSON, so hashing, the state views and the endorse-tx comparison rule (#2436) are unchanged; conversion happens at the six send sites, at decode and in the store. Receivers turn an envelope back into JSON and validate it with ValidateReceived as before. The finality view also accepts a FinalityRequest with a routing key. Two contract steps (#2460) move stored data: the endorse-tx store's step 2 rewrites JSON transactions as envelopes and the vault's step 2 rewrites gob metadata as protobuf. migrate.ReadableByObserver tells a store its readable_by at every open, so it writes the old form until the step has run and the new form afterwards. Each step pages 1000 rows by keyset inside one transaction, rewrites a row only when the new form reads back to the same value (the same metadata map; the same transaction apart from TProposal, nil versus empty RWSet, TParameters and TTransient, and the channel key, which the envelope's routing fields carry), and updates with compare-and-set, so a write by a replica during the step is kept. Endorse transactions without a channel key, as v0.27 Fabric-x nodes wrote them, and those of a platform the binary has no format for stay JSON. Tests: conversion and strict decoding for both platforms, decoding with the Fabric protos alone and signatures over the signed bytes, both response encodings, both steps on SQLite and Postgres including a concurrent write and edge keys at page boundaries, the release fixtures, a fuzz target, and an iou integration spec with a lender that supports only version 1. Docs: messages between nodes, signature coverage, the contract steps, the protobuf rule for new wire messages, the format registry, and the v0.27 to v0.28 upgrade guide. BREAKING CHANGE: after `node migrate --contract`, v0.27 binaries can no longer open the endorse-tx store or a vault. A store a v0.28 binary creates runs the steps at first open. An application transaction type whose JSON has fields outside FSC's fails to send at version 2. LoadTransaction can return an envelope. Fixes #2457 Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>

The documentation is generated from this commit.

2026-11-04

feat(view): negotiate FSC formats per session (#2474) Organizations upgrade on their own schedule, so a node talks to peers of its own release and of the previous one at once. Two nodes now use, per session, the highest version of each component's formats that both support. Components: every binary publishes FSC's view, fabric and fabricx at {1, 1} (preamble.FSCComponents). An application adds its own with preamble.RegisterComponent(name, min, max) when its SDK is built or in main, which re-encodes the preamble. Registering before the node starts, the way store schemas are registered, lets node version --json and node peers --check, which install no SDK, report application components too. A duplicate name panics with both ranges in the message, and so does an invalid one. Components are process-wide, like the FSC version. Negotiation: a session this node opened, with NewSession or with an agreed ID through NewSessionWithID, chooses per local component the highest version in both ranges, from the preamble of the stream it sends on. Two nodes that open a session by ID each negotiate and pick the same version. A component the peer does not list, or a peer without a preamble, counts as {1, 1}; a component without overlap is stated as version 0, so both sides fail on it. view.VersionedSession.Version(ctx, component) negotiates on first use, opening the stream if needed, so a codec can pick its encoding before it encodes the first payload; view.SessionVersion returns 1 for a session that does not implement the interface. Every initiator message states the versions and the protocol name (ViewPacket fields 6 and 7, ignored by older peers), so the responder learns them from whichever message reaches it first. The versions travel as an encoded preamble.ComponentVersions of at most 4 KiB, refused unread when larger, so a peer cannot make a node allocate for them more than it sent. The responder rejects a version outside its range, 0, or a list that does not decode with no_common_version, mapped to view.ErrNoCommonVersion by session.RejectionError. Payload bytes do not change. Protocol names: an initiator view implements view.ProtocolView (Protocol() (component, name)) and the responder registers with view.WithProtocol. GetSession states the name of the view it opens the session for, so bundled views that pass Initiator() run under the application's protocol. Dispatch looks the name up first, then the type path, so a stale type-path registration cannot shadow the responder and authorizer registered for the name. Names live in their own map, so a type path that looks like a name (main/initiator) is never found as one. A name belongs to one initiator; registering it for another fails. ResponderForCaller takes the protocol name as well as the caller. comm.Service.PeerRanges and P2PNode.PeerPreamble are removed: negotiation reads the preamble of the session's own stream, and nothing else used them. Tests: version choice (the highest of {1, 3} and {2, 5} is 3), for sessions from NewSession and NewSessionWithID; missing preamble and missing component; no overlap; a closed session; the stated fields on every message and the 4 KiB cap; responder checks and the dispatch rejection; protocol routing after the initiator type moved, the name winning over a type path that resolves elsewhere, name ownership and re-registration; component registration and duplicates; node version --json reporting a registered component. The pingpong suite routes its Initiator by protocol name, adds a spec where nodes supporting pingtest {2, 3} and {1, 2} both observe version 2, and checks that node peers --check reports pingtest with both ranges. Docs: programming model (protocol names, format versions), comm readme (format negotiation, the new rejection), metrics catalog, node CLI reference, and the v0.27 to v0.28 upgrade guide. Fixes #2456 Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>

2026-11-03

feat(comm): stream preamble with version ranges and a framing epoch (#2464) Nothing on the wire said what a node supports, so two nodes of releases that cannot talk to each other found out through a decode error or a timeout. Every stream now opens with a preamble (package comm/preamble) that carries the FSC version and revision, a framing epoch, and per component (view, fabric, fabricx) the range of wire format versions the binary supports, all at {1, 1}. A node refuses a peer whose framing epoch differs with an error that starts with "version: ", names both epochs and wraps preamble.ErrEpoch; FSC versions are only logged. Transports read the preamble only after they have authenticated the peer, and refuse one over 4 KiB or with a string over 256 bytes. WebSocket (multiplexed provider): the client sends its preamble in StreamMeta on every sub-connection, and the server sends its own in an Fsc-Preamble header on the upgrade response, so the dialing initiator learns the responder's ranges too. A server refuses a sub-connection with an Err frame and keeps the websocket; a client closes the websocket it dialed. A peer without a preamble runs an older release, is accepted, and is logged once. The test-only SimpleProvider carries no preamble. libp2p: a node registers /fsc/view/2.0.0 next to /fsc/view/1.0.0 and dials 2.0.0 first, so a peer that only knows 1.0.0 still connects. On 2.0.0 both sides exchange one length-prefixed frame, read without a buffered reader so the following view packets stay on the stream, within 30 seconds or the dialer's context. A frame over 4 KiB is refused before it is allocated. A refused stream is reset. The transports count refusals in ws_rejected_streams{reason} and libp2p_rejected_streams{reason}, with reason version, rather than going through the view P2P service's reject: the preamble is checked before any ViewPacket is read, and a peer of another epoch may not read our framing. Each stream carries the peer's preamble (host.PreambleStream), and comm.Service.PeerRanges(pkid) returns the ranges of the newest live stream to the peer. make buf-breaking checks the FSC protos under platform/view against the latest release tag with buf's FILE rules, and the CI job buf.yml runs it when a proto, buf.yaml, the Makefile or tools/go.mod changes. buf is pinned at v1.74.0 in tools/, the release that keeps the pinned google.golang.org/protobuf. The build-info parsing of node version moves to pkg/utils/buildinfo so the preamble can use it without importing the CLI. Docs: the comm readme, the WebSocket and libp2p pages, the metrics catalog, the v0.27 to v0.28 upgrade guide, and the conventions and development guides. Fixes #2455 Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>

2026-10-22

feat(view)!: remove InitiateView, bind commands to the client certificate, add a remote timeout (#2220) Three changes to the view service that every transport relies on. InitiateView is removed. It started a view in a goroutine on the request context, which gRPC cancels as soon as the handler returns, and answered with a context ID that no API could query; nothing called it but its own tests. CallView, unary or streamed, is the only command of the view service, and commands.proto reserves the removed field numbers and names. The view service checks a command's tlsCertHash against the client TLS certificate of its connection whenever the listener verified one, and binds nothing otherwise. The rule depends only on the connection, so it holds for any listener that serves the view service, whatever its client-authentication mode. fsc.view.remote.timeout (default 2m) bounds CallView and StreamCallView in the shared gRPC view handler and on the REST routes. A view still running when it expires ends with "view execution timed out"; a view that fails with a deadline error of its own, while the handler's deadline has not passed, reports that failure. Local view calls keep their caller's context. The view handler's tracer, idle once InitiateView was gone, and its fsc_view_services_view_grpc_server_view_handler metric family are dropped. Part of #2123. BREAKING CHANGE: the view service no longer accepts InitiateView; the gRPC view client's Initiate and the web client's Initiate stub are removed. On a listener with clientRootCAs but without clientAuthRequired, a client that offers a certificate must name it in tlsCertHash. fsc.web.viewTimeout is removed in favour of fsc.view.remote.timeout, and a configuration that sets the old key fails to start; gRPC view calls, which had no server-side bound, are cut off after it. sdk.NewViewServiceServer drops its *grpc.GRPCServer parameter; server.InstallViewHandler takes the timeout instead of a tracing.Provider; grpc.NewBindingInspector, grpc.BindingInspector and grpc.CertHashExtractor are removed. Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>

2026-09-15

refactor(grpc)!: unify gRPC/TLS config (#1813) * refactor(grpc,tls)!: unify gRPC/TLS config Fabric-x's committer query-service client had no way to raise gRPC's 4 MiB default receive limit, so large result sets failed with `ResourceExhausted` (#1799). Fixing that surfaced a second, hand-rolled gRPC client in `platform/fabricx/core/committer/grpc` duplicating most of `platform/view/services/grpc`, with fewer knobs and its own TLS credentials builder that existed only to pin TLS 1.3. This unifies both: - Moves `platform/view/services/grpc` to `platform/common/services/grpc` and `platform/view/services/tlsconfig` to `platform/common/services/tlsconfig`, since fabric, fabricx, and view all consume them. No compatibility alias remains at the old paths. - Adds configurable `MaxRecvMsgSize`/`MaxSendMsgSize` to `ServerConfig`, `ClientConfig`, and `ConnectionConfig`. Zero still falls back to the existing 100 MiB package default. - Adds a configurable TLS version range (`MinVersion`/`MaxVersion`) to `SecureOptions` and the `ServerTLS`/`ClientTLS` wire types, with the same nil-inherits rule as every other TLS field. - Deletes `platform/fabricx/core/committer/grpc`. Its endpoints become `commongrpc.ConnectionConfig`, and `ClientProvider` moves to `platform/fabricx/core/committer/config` on `lazy.Provider`, replacing its own two `sync.Map`s and hand-rolled locking. `NewClientProvider` and `ServiceConfigProvider` now live in that package. - Fabric-x's TLS 1.3 requirement, previously a forked `TransportCredentials`, is now `minVersion: 772` in its own `tls:` block. New configuration keys: - `fsc.grpc.maxRecvMsgSize` / `maxSendMsgSize` - Per-endpoint `maxRecvMsgSize` / `maxSendMsgSize` (Fabric peers/orderers, fabricx query/notification services) - `minVersion` / `maxVersion` in any `tls:` block (771 = TLS 1.2, 772 = TLS 1.3) No existing default changes: an unset client still resolves to TLS 1.2-1.3 and 100 MiB message limits; an unset listener still negotiates TLS 1.2 exactly, as it always has. Test plan: `make checks` clean across all five modules; unit tests cover the message-size fallback/override on all three config structs and the TLS version-range resolution and validation. The integration suite needs Fabric binaries and Docker and is left to CI, not run locally for this pass. Closes #1799 Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com> * fix(fabricx,grpc): restore fabric-x's TLS 1.3 floor, test the unconfigured-version fallback Unifying fabric-x's committer client onto the shared gRPC client dropped its TLS 1.3 requirement: an endpoint with no minVersion configured now negotiated the shared 1.2-1.3 range instead. resolveEndpointTLS raises the floor to TLS 1.3 whenever an endpoint's resolved MinVersion is still zero, so an unconfigured fabric-x endpoint keeps requiring 1.3 while every other client keeps defaulting to 1.2-1.3. TestNewGRPCServerVersionRange gains a case that builds a listener with no MinVersion/MaxVersion at all -- the state every deployment with no tls version keys reaches -- and checks both that a client willing to negotiate up to 1.3 lands on exactly 1.2, and that a TLS-1.3-only client is refused. docs/configuration.md no longer describes fabric-x's TLS-1.3 floor as something a deployment must configure by hand. Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>

2026-08-25

chore(spelling): fix spelling of comments, log messages, and errors (#1670) * chore(spelling): fix spelling of comments, log messages, and errors (#1670) Corrects typos found in Go comments and doc comments across the root and integration modules. Comment-only; no behavioural change. Fixes typos in user-visible error strings, one debug log message, and the commands proto comments. The endpoint service test that asserts on "cannot find the idnetity" is updated alongside its source string. commands.pb.go carries the same comment fix as commands.proto, applied directly rather than by running generate-protos, so the generated file is not churned by an unrelated protoc version stamp. Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>

2026-06-15

feat(build): add make target for proto generation (#1535) Signed-off-by: Said Altury <Said.Altury@ibm.com>

2026-02-10

benchmarks: more grpc benchmarks (#1126) * benchmarks: more grpc benchmarks - add grpc benchmarks for remote deployments (separate client/server) - add view api grpc benchmarks for remote deployments - remove redundant benchmarks - update plot scripts Co-authored-by: Said Altury <109276519+SaidAltury-ibm@users.noreply.github.com> Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>

2025-10-27

Cleanup protobuf - update protobuf deps - add make target to generate all protos - re-generate all protos with protov2 - add protov1 adapter for idemix protos Signed-off-by: Alexandros Filios <alexandros.filios@ibm.com> Signed-off-by: Marcus Brandenburger <bur@zurich.ibm.com>

2025-07-09

view platform: architecture #975 (#976) Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

2025-02-05

remove badger Signed-off-by: Angelo De Caro <adc@zurich.ibm.com> Signed-off-by: Alexandros Filios <alexandros.filios@ibm.com>

2025-01-31

Simplify vault Signed-off-by: Alexandros Filios <alexandros.filios@ibm.com>

2024-11-11

remove IsTxFinal. Each application must handle this separately Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

2024-10-20

db and vault support for generic version Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

2024-04-18

common platform (#547) Signed-off-by: Alexandros Filios <alexandros.filios@ibm.com> Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

2024-04-10

enhanced commit pipelines (fabric and orion) (#539) Signed-off-by: Angelo De Caro <adc@zurich.ibm.com> Signed-off-by: Alexandros Filios <alexandros.filios@ibm.com>

Fix race conditions in tests (#542) Signed-off-by: Angelo De Caro <adc@zurich.ibm.com> Signed-off-by: Alexandros Filios <alexandros.filios@ibm.com>

2023-08-11

Various Utilities in Support of the Token-SDK (#487) Signed-off-by: Angelo De Caro <angelo.decaro@gmail.com> Signed-off-by: Alexandros Filios <alexandros.filios@ibm.com>

2022-09-16

view/services/db: orion-based driver (#303) Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

2022-03-25

Orion (#255) Orion integration Signed-off-by: Hagar Meir <hagar.meir@ibm.com> Co-authored-by: Angelo De Caro <adc@zurich.ibm.com>

2021-10-05

Remove idemix We remove the local implementation of idemix and use the one provided at https://github.com/IBM/idemix Signed-off-by: Alessandro Sorniotti <aso@zurich.ibm.com>

2021-07-27

Update dependencies Signed-off-by: Yacov Manevich <yacovm@il.ibm.com>

2021-07-16

bug fix #76 #77 - [x] network/channel support for IsTxFinal #77 - [x] nwo: fabric platform's Name() does not return the topology name #76 Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

2021-07-01

- web client - refactoring Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

2021-06-28

view service: cleanup proto messages #53 Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>

2021-06-02

The Fabric Smart Client, first drop of code. Signed-off-by: Angelo De Caro <adc@zurich.ibm.com> Signed-off-by: Kaoutar Elkhiyaoui <kao@zurich.ibm.com> Signed-off-by: Mathilde Ffrench <mathilde.ffrench@fr.ibm.com> Signed-off-by: Alessandro Sorniotti <ale.linux@sopit.net>