dddd6c57cd
This changes how we read performance metrics from the Go runtime. Instead of using runtime.ReadMemStats, we now rely on the API provided by package runtime/metrics. runtime/metrics provides more accurate information. For example, the new interface has better reporting of memory use. In my testing, the reported value of held memory more accurately reflects the usage reported by the OS. The semantics of metrics system/memory/allocs and system/memory/frees have changed to report amounts in bytes. ReadMemStats only reported the count of allocations in number-of-objects. This is imprecise: 'tiny objects' are not counted because the runtime allocates them in batches; and certain improvements in allocation behavior, such as struct size optimizations, will be less visible when the number of allocs doesn't change. Changing allocation reports to be in bytes makes it appear in graphs that lots more is being allocated. I don't think that's a problem because this metric is primarily interesting for geth developers. The metric system/memory/pauses has been changed to report statistical values from the histogram provided by the runtime. Its name in influxdb has changed from geth.system/memory/pauses.meter to geth.system/memory/pauses.histogram. We also have a new histogram metric, system/cpu/schedlatency, reporting the Go scheduler latency. |
||
|---|---|---|
| .github | ||
| accounts | ||
| assets/images | ||
| bmt | ||
| build | ||
| cicd | ||
| cmd | ||
| common | ||
| compression/rle | ||
| consensus | ||
| console | ||
| containers/docker | ||
| contracts | ||
| core | ||
| crypto | ||
| docker | ||
| eth | ||
| ethclient | ||
| ethdb | ||
| ethstats | ||
| event | ||
| genesis | ||
| internal | ||
| les | ||
| light | ||
| log | ||
| metrics | ||
| miner | ||
| node | ||
| p2p | ||
| params | ||
| rlp | ||
| rpc | ||
| swarm | ||
| tests | ||
| trie | ||
| XDCx | ||
| XDCxDAO | ||
| XDCxlending | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml.bak | ||
| COPYING | ||
| COPYING.LESSER | ||
| Dockerfile | ||
| Dockerfile.bootnode | ||
| Dockerfile.node | ||
| go.mod | ||
| go.sum | ||
| interfaces.go | ||
| Makefile | ||
| README.md | ||
XDPoSChain
XinFin XDPoSchain
Enterprise ready hybrid blockchain for global trade and finance
XinFin Hybrid Blockchain
XinFin Hybrid Blockchain is an Enterprise ready Blockchain for global trade and finance
Visit: XinFin.org Contribute: Developer Docs
XinFin Network XDPoS is community driven project to achieve the following
-
XinFin DPOS (XDPoS) consensus that selects 108 set of Masternodes to achieve a high throughput Energy efficient consensus with instant block finality
-
KYC Enforcement on Masternodes for Enterprise Adoption and compliance
-
Ability to port/relay limited set of data and transactions from privacy channels to public channel
-
Interoperability between applications hosted on Private Blockchains like Corda, Hyperledger, Quorum(JP Morgan) using relayers to XinFin Network
-
Customer Centric and consortium driven Governance to equally benefit the validators as well as providing comfort for large scale enterprise applications to be hosted on the Network. This achieves
-
Rapid Upgradability
-
DApps Standardisation for rapid commercialisation
-
Compliance with major global jurisdictions.
-
KYC for masternodes
OVERVIEW
To add a layer of KYC for masternodes in the current system and a sense of ownership amongst the masternodes hence tying such a cluster of masternodes to physical entity which can held accountable for its actions.
Design
We established a bidirectional connection between a candidate and its owner inorder to retrieve a candidate belonging to a specific owner & vice versa.
All the masternodes are recognized by the KYC of their owners and hence are considered as a single verified entity ( for eg. while voting for invalid KYC, only one vote is considered per such cluster )
The contract is very strict in handing out penalty for invalid KYC, it results loss of all funds invested in all of its candidates.
For eg. say A proposes condidates B,C,D by paying for its proposal cost. If at a later stage if some predecided amount of owners ( investors ) vote that a KYC for a A is invalid then A & all of its candidates (B,C,D) will lose their position & all their funds will be lost ( will remain with contract wallet ).
For developers
Continues integration & delivery
See https://github.com/XinFinOrg/XDPoSChain/tree/dev-upgrade/cicd
To contribute
Simple create a pull request along with proper reasoning, we'll get back to you.
Our Channels : Telegram Developer Group or XDC.Dev