3
These are high level characteristics for the json files:
identity.json stores the proof that the node id belongs to this node. This proof disallows others to use your node id and act poorly to get your node banned from other peers. This node id is used by other node peers to identify your node so it can make decisions whether or not to trust your node. Note ...
2
Yes, the old testing networks are abandoned and brand new networks are launched using the new to-be-activated protocol.
For instance, Carthagenet will be deactivated on 12/12/2020. The current Delphinet test network will remain as a protocol copy of mainnet. Edonet was launched yesterday, which is using the upcoming beta 008 protocol.
2
We (Obsidian Systems) update the version of Tezos that Kiln uses when we do new Kiln releases. When you upgrade Kiln, your node will momentarily be offline. When Kiln restarts, your node will start up again.
Best time for your upgrades is when you do not have opportunities to bake or endorse a block since they will be missed when your node is down.
2
This is normal. It is waiting for the switch over to the new protocol(Athens). Once the network switches over the 003's will turn off and the 004's will start up.
2
Stored lambdas approach:
It allows any packable value as a parameter and the method that computes the new value can be updated.
import smartpy as sp
class Upgradable(sp.Contract):
def __init__(self, **kargs):
self.init(**kargs)
@sp.entry_point
def calc(self, data):
self.data.value = self.data.logic(data)
@sp.entry_point
def updateLogic(...
1
You could do something like this:
Or just store upgradable structures as bytes and lambdas to unpack/pack and process those bytes. (Expensive and doesn't work with big maps)
Is it feasible to this without giving the admin developer too much
power?
No, having an upgradable contract means that the contract can change its behavior to do unintended things. ...
1
Another way is dependency injection: the upgradable contract takes as a parameter a contract address or a lambda that is called. The caller can thus "upgrade" the original contract by varying the supplied address / lambda. The pro is also the con of this approach: it allows the the contract client to interact with the contract in ways the contract ...
1
I went back and redid everything, apparently I may have had mistake during conversion, and maybe was using wrong binary versions between the node/baker, etc.
Someone helped me log the actual cause:
Error: State.Chain.get_level_index_protocol
which indicates that there is some kind of incompatibility between the baker daemon and node data...
Only top voted, non community-wiki answers of a minimum length are eligible