Releases: orbs-network/orbs-network-go
Elections delegation fix
This is a hotfix release fixing (#1502) a bug introduced in v1.3.2 due to a change in how go-ethereum parses events. The _Elections Orbs contract mirrors delegation data from Ethereum. There are two methods of expressing delegations: a delegator can either transfer 0.07 ORBS to the delegate, or she can explicitly call OrbsVoting.delegate on Ethereum.
In the Orbs contract, events are read from Ethereum and applied to the Orbs state so that Orbs reflects the state changes in Ethereum. The event is parsed to a Golang struct, which was missing the delegationCount field. v1.3.2 upgraded go-ethereum from v1.8.18, which was lenient towards missing fields when parsing events to structs, to v1.9.6, which isn't lenient. As a result, all explicit delegation events emitted after November 24th, which is when v1.3.2 was deployed to mainnet, have not been mirrored.
Other changes included in this release:
- #1462 - prevents Gossip from broadcasting messages when multicast was requested. This fix will prevent view change messages from begin delivered to all nodes rather than only to the leader.
- #1475 - upgrades Scribe (logger library) to v0.2.3
- #1477, #1478, #1480 #1487 - various logging changes to help troubleshoot production issues
v1.3.2
Scribe logger fix
- Fixed a bug causing Scribe to truncate the log file on each write.
- Recovering and reporting errors that happen during logging.
Triggers and reputation fix
Fixed an issue with trigger transactions (and the leader reputation mechanism built on top of it). Prior to this fix, trigger transactions were created with an empty signer which is considered invalid by the contract SDK. This was fixed by assigning a dummy value for the signer field when not present.
New types for public contract methods
The types used for defining the arguments and return values of public contract methods now include bigint (uint256), bool, byte[20] and byte[32], and also array type arguments.
Lean Helix cancellation bugfix
Prior to this fix, concurrent handling of an election trigger and a view-change event could cause a cancellation of the new view for the leader node. This stalls consensus on the entire network until the next election timeout.
Early serving of metric HTTP endpoints
The node will now respond to metric-related HTTP requests immediately, without waiting for the completion of the entire initialization process (which involves a heavy and time consuming processing of the block file).
More Efficient Block Indexing
Added a buffering layer for block file reads, which speeds up block indexing by a factor of 5-10.
v1.3.0
v1.2.2
Time-based Elections
This feature will be deployed turned off, the network will switch to time-based elections independent of version upgrade, by configuration update
Elections are now triggered every set time. This makes next election time deterministic, as opposed to the previous mechanism where elections were triggered based on Ethereum block-number.
Triggers
Triggers enable a virtual chain to trigger a contract's method automatically with a need for a user-generated transaction. Triggers may be used to perform time-based operations or add additional processing to every block. Triggers are implemented by adding to every block, a special transaction generated by the network. The transaction is processed similarly to a regular transaction generating a receipt and state modification if needed. The first use case is for updating the validator's Reputation - see below.
Reputation
This feature will be deployed turned off, the network start taking reputation into account independent of version upgrade, by configuration update
Leader reputation is used in order to reduce the probability of a malfunction or misbehaving validator as a leader. Orbs Lean Helix consensus algorithm is based on an ordering committee chosen for each block creation. The first validator in the ordered committee is the first to propose a block. as Lean Helix (based on PBFT) is based on timeouts in case of a misbehaving leader, the presence of such a leader may result in a delay in the block creation. By reducing the probability of misbehaving validators to take part as leaders, their impact on the consensus is minimized. The reputation is calculated under consensus and may be used as a means by the Orbs PoS ecosystem and in particular Orbs Guardians to evaluate misbehaving validators and vote them out of the Validators list. Reputation is loosely based on the rate of a leader "missing" closing a block.
Lean-Helix liveness fix
A significant upgrade for Lean-Helix - a new goroutine now provides instantaneous handling of incoming protocol messages and events. Previously, a single goroutine handled messages and events, and in addition was used to call and wait on external, time-consuming services, such as collecting transactions into a new proposed block. While the goroutine was blocked on the external service, it would not process anything else, resulting in reduced (sometimes significantly) response time.
The consensus algorithm is now far less likely to experience slowdowns as it now has a dedicated goroutine for handling incoming external events and protocol messages, and it will cancel a blocking call to an external service if an incoming message/event made that call obsolete.
Gossip liveness
Gossip (the component that communicates between nodes) now allocates a separate goroutine per-topic (transaction forwarding, consensus, etc.). This prevents liveness issues where for example transactions would not be forwarded to a certain node, just because it was blocking on a consensus message.
Switched dependency management from vendoring to Go modules
The new Go Modules dependency management allows for tighter control over dependency versions, flat dependency structure, better integration with IDE and more.
Upgraded to Go 1.12.6
The codebase is compiled using Golang 1.12.6, and the Go language contract compiler will compile contracts using the same version.
