@did-btc1/method / Beacon
Class: abstract
Beacon
Defined in: packages/method/src/interfaces/beacon.ts:36
Implements 5. Beacons. Beacons are the mechanism by which a DID controller announces an update to their DID document by broadcasting an attestation to this update onto the public Bitcoin network. Beacons are identified by a Bitcoin address and emit Beacon Signals by broadcasting a valid Bitcoin transaction that spends from this Beacon address. These transactions include attestations to a set of didUpdatePayloads, either in the form of Content Identifiers (CIDs) or Sparse Merkle Tree (SMT) roots. Beacons are included as a service in DID documents, with the Service Endpoint identifying a Bitcoin address to watch for Beacon Signals. All Beacon Signals broadcast from this Beacon MUST be processed as part of resolution (see Read). The type of the Beacon service in the DID document defines how Beacon Signals SHOULD be processed. did:btc1 supports different Beacon Types, with each type defining a set of algorithms for:
- How a Beacon can be established and added as a service to a DID document.
- How attestations to DID updates are broadcast within Beacon Signals.
- How a resolver processes a Beacon Signal, identifying, verifying, and applying the authorized mutations to a DID document for a specific DID. This is an extendable mechanism, such that in the future new Beacon Types could be added. It would be up to the resolver to determine if the Beacon Type is a mechanism they support and are willing to trust. If they are unable to support a Beacon Type and a DID they are resolving uses that type then the DID MUST be treated as invalid. The current, active Beacons of a DID document are specified in the document’s service property. By updating the DID document, a DID controller can change the set of Beacons they can use to broadcast updates to their DID document over time. Resolution of a DID MUST process signals from all Beacons identified in the latest DID document and apply them in order determined by the version specified by the didUpdatePayload. All resolvers of did:btc1 DIDs MUST support the core Beacon Types defined in this specification.
Beacon
Extended by
Implements
Constructors
Constructor
> new Beacon(__namedParameters
, sidecar?
): Beacon
Defined in: packages/method/src/interfaces/beacon.ts:42
Parameters
__namedParameters
sidecar?
undefined
Returns
Beacon
Properties
id
> id: string
Defined in: packages/method/src/interfaces/beacon.ts:37
A unique identifier for the Beacon
Implementation of
serviceEndpoint
> serviceEndpoint: DidServiceEndpoint
Defined in: packages/method/src/interfaces/beacon.ts:39
The service endpoint of the Beacon
Implementation of
sidecar?
> optional
sidecar: undefined
Defined in: packages/method/src/interfaces/beacon.ts:40
type
> type: string
Defined in: packages/method/src/interfaces/beacon.ts:38
The type of the Beacon
Implementation of
Accessors
service
Get Signature
> get abstract
service(): BeaconService
Defined in: packages/method/src/interfaces/beacon.ts:52
Returns the Beacon Service object.
Returns
Returns the Beacon Service object
Implementation of
Methods
broadcastSignal()
> abstract
broadcastSignal(didUpdatePayload
): Promise
<SignalsMetadata
>
Defined in: packages/method/src/interfaces/beacon.ts:67
Broadcasts a Beacon Signal (implemented by subclasses).
Parameters
didUpdatePayload
DidUpdatePayload
Returns
Promise
<SignalsMetadata
>
Implementation of
generateSignal()
> abstract
generateSignal(didUpdatePayload
): BeaconSignal
Defined in: packages/method/src/interfaces/beacon.ts:57
Generates a Beacon Signal (implemented by subclasses).
Parameters
didUpdatePayload
string
Returns
Implementation of
processSignal()
> abstract
processSignal(signal
, signalsMetadata
): Promise
<undefined
| DidUpdatePayload
>
Defined in: packages/method/src/interfaces/beacon.ts:62
Processes a Beacon Signal (implemented by subclasses).
Parameters
signal
RawTransactionV2
| RawTransactionRest
signalsMetadata
Returns
Promise
<undefined
| DidUpdatePayload
>