mirror of
https://github.com/luxfi/proto.git
synced 2026-10-30 15:21:09 +00:00
zeekayandHanzo Dev
938b06d485
proto required luxfi/node and luxfi/node required proto, with no replace directive on either side. The cycle was not load-bearing: most of it was proto reaching into the node for packages proto already owns — p/warp, p/txs, p/signer, p/stakeable, p/security, x/txs — which now name themselves. Two were real. The UTXO components moved here, where the chains that use them already live, and the node is the only other caller, so that dependency now runs one way. And p/config held the node's chain manager to queue a chain the P-Chain had accepted a CreateChainTx for; it calls one method, so it declares one method. A P-Chain that imports the node to describe QueueChainCreation is what made two modules require each other. Dropping the requirement dropped a registration with it: lux.ParseUTXO is a registry filled by an init, which the node used to link in on proto's behalf. The packages that call it now say so themselves. Co-authored-by: Hanzo Dev <[email protected]>
37 lines
1.3 KiB
Go
37 lines
1.3 KiB
Go
// Copyright (C) 2019-2025, Lux Industries, Inc. All rights reserved.
|
|
// See the file LICENSE for licensing terms.
|
|
|
|
package config
|
|
|
|
import "github.com/luxfi/ids"
|
|
|
|
// ChainParameters is what the P-Chain knows about a chain it has accepted a
|
|
// CreateChainTx for: enough to ask for the chain, and nothing about how one
|
|
// gets built.
|
|
type ChainParameters struct {
|
|
// ID is the chain being created, which is the transaction that created it.
|
|
ID ids.ID
|
|
// ChainID is the network the chain belongs to.
|
|
ChainID ids.ID
|
|
// GenesisData is passed to the VM at initialization, uninterpreted here.
|
|
GenesisData []byte
|
|
// VMID names the VM to run it.
|
|
VMID ids.ID
|
|
// FxIDs name the feature extensions the VM is given.
|
|
FxIDs []ids.ID
|
|
// Name is for logs and for people.
|
|
Name string
|
|
}
|
|
|
|
// ChainCreator is asked to bring a chain into being. The P-Chain accepts the
|
|
// transaction that says a chain exists; something above it does the creating,
|
|
// and this is the whole of what the P-Chain needs to say so.
|
|
//
|
|
// It is declared here, where it is called, rather than imported from the node
|
|
// that implements it. The P-Chain is a chain the node runs, so a P-Chain that
|
|
// imports the node to describe one method makes the two modules require each
|
|
// other.
|
|
type ChainCreator interface {
|
|
QueueChainCreation(ChainParameters)
|
|
}
|