We are an early-stage research and development startup. Our ambitious goal is to build a system capable of understanding knowledge, to answer questions and get things done. Our work leverages cutting-edge domains such as Probabilistic Programming and Applied Category Theory.
Skill areas:
- Julia software engineering: to build our core system
- Research across areas: to develop our theoretical framework
"For some of you, it is difficult enough to keep everyone up to date with the tasks at hand. It is even more so when they involve codes. Lots of codes."
Turing has more things that work out of the box, so if you do not have complex requirements its a good first step. Gen allows for composing models using its generative function interface, you can specify models in different ways. You can also have fine grained control over inference, rather than a few preset methods.
Gen has also worse error messages and docs.
We’re building the future of identity, privacy, financial markets and commerce through blockchains and other cryptographic technologies. At the core of this work is Polkadot - a platform that enables blockchains of all kinds to interact and stay secure. This is an opportunity to work at the forefront of technological development and join in shaping the future of society.
Security is at the heart of decentralised protocols and applications. Extensive reliance on correct implementation and good user practices necessitates that we spend sufficient time on Security in the Web3 ecosystem.
Web3 Foundation aims to ensure that crucial projects and networks are sufficiently reviewed and monitored, as well as any developers and users are aware of best security practices. The Security team will be responsible for the initiatives that allow us to achieve those goals together with our open source community.
Proof of work is not the right tool for private networks since it is not sybil resistant in this context. https://github.com/paritytech/parity/wiki/Demo-PoA-tutorial is another tutorial that uses a Proof of Authority consensus for an Ethereum-like chain.
PoW is not often used in consortium networks because there is no need for the excess power usage when the blockchain network is not in the public domain and participation is limited by some form of authority or centralised management structure.
I'm not sure what you mean with sybil resistance in this context though. Do you mean to say that PoA reduces the "51% attack" vector?
The way people try to use PoW for consortium networks does not cause excess power usage: low difficulty, low powered device/s.
Anyone malicious that connects to the network can easily overpower the existing validators. Sybil resistance is only the case if validators compete with computation due to economic incentives. In consortium network the native tokens have likely no/low value.
With PoA there are rules according to which validators are added/removed and limits on block issuance that ensure fault tolerance.
I'm not sure I agree with you re: overpowering the existing validators.
On a public blockchain, you need a proof that all nodes are acting in the best interest of the network because there is no way of stopping anyone from joining. The economic incentives play a huge part here as you mention.
On a private chain, you'll have some form of registration or centralised auth which prevents "unknown" nodes from joining in the first place. If mining is centralised, that means that trust is established "off-chain" so an external sybil attack would not be a real threat.
Regarding the power usage and difficulty increase over time, I guess you could keep the resource usage low for some time, but you'd need to re-write the client software to prevent and increase in proportion to the number of blocks created, which could have a negative effect on the network synchronisation, or rate of inflation (coin issuance) if there is a token involved.
What is the point of blockchain if there is no fault tolerance, under your private PoW scenario as soon as a single node goes rogue the security guarantees disappear and the chain is messed up.
With this PoA you can keep a well functioning chain and kick misbehaving nodes (up to 50% of validators for this consensus engine) in due time.
I'm not sure I can agree with you. To my mind with a private blockchain there is always off-chain trust or contract limiting access to the network. (edit: regardless of the consensus algorithm used).
In order to re-write historic transactions, an attacker would need to convince other participants to accept the new chain as valid and drop the old one, which is would be prevented by the off-chain trust model in the first place.
A powerful "rogue" node that starts producing blocks with different validation rules would be automatically ignored by other validator nodes who would not recognise the blocks as valid, so here again the risk of a successful sybil attack is limited.
Fault tolerance seems to be a red herring here because but I would rather ask you to expand on what you mean.
First you need to understand what is a fault in this case. If you make use of PoW the chain is picked on the basis of total difficulty, this means that if any validator (already admitted by a centralised party) is hacked, then they can very quickly produce a chain which gets accepted by all others as canonical (with higher difficulty). This reverses any existing transactions and requires significant extra-protocol action to mitigate.
With PoA there is no such ability, since the canonicality is not abusable. Furthermore addition and removal of nodes can be decentralised and determined according to any rules (since validators can be specified in a contract). This makes it possible to include validators based on something like majority voting.
I understand that if one node is compromised, it can then be used to generate malicious txs and the attacker can try to add them to a block it generates, but why would you say the other validators accept such block(s) or transactions in the first place?
It seems to me that a successful attack on a private blockchain requires the attacker gaining access to both a "pre-approved" node and having the hashrate majority needed to ensure its blocks are generated faster than the rest of the network combined.
We are an early-stage research and development startup. Our ambitious goal is to build a system capable of understanding knowledge, to answer questions and get things done. Our work leverages cutting-edge domains such as Probabilistic Programming and Applied Category Theory.
Skill areas:
- Julia software engineering: to build our core system
- Research across areas: to develop our theoretical framework
Useful experience: algorithms, Bayesian statistics, symbolic computing, optimization, category theory.
Find more on our website, and apply to join us: https://planting.space/joinus