updated FAQ

content/_index.md

@@ -6,7 +6,7 @@ title: Logos Technical Roadmap
 - [Network Requirements](requirements/overview.md)
 - Research and Development Roadmap
 	- [Consensus](roadmap/consensus/overview.md)
-	- Virtual Machines
+	- [Virtual Machines](roadmap/virtual-machines/overview.md)
 	- Economics
 	- Data Model
 	- Applications / Wallets

content/requirements/overview.md

@@ -6,3 +6,11 @@ tags:
 
 This document describes the requirements of the Logos Network.
 
+>  Network sovereignty is an extension of the collective sovereignty of the individuals within. 
+
+> Meaningful participation in the network should be acheivable by affordable and accessible consumer grade hardware.
+
+> Privacy by default. 
+
+> A given CiC should have the option to gracefully exit the network and operate on its own.
+

content/roadmap/consensus/candidates/logos-bft/FAQ.md

@@ -0,0 +1,30 @@
+---
+title: "Frequently Asked Questions"
+tags:
+  - "LogosBFT"
+  - "consensus"
+---
+
+
+#### How much failure rate of erasure code transmission are we expecting. Basically, what are the EC coding parameters that we expect to be sending such that we have some failure rate of transmission? Has that been looked into? - Dmitriy
+>This is a great question and it points to the tension between the failure rate vs overhead. We have briefly looked into this (today me and Marcin @madxor discussed such cases), but we haven’t thoroughly analyzed this. In our case, the rate of failure also depends on committee size. We look into $10^{-3}$ to $10^{-6}$ probability of failure. And in this case, the coding overhead can be somewhere between 200%-500% approximately. This means for a committee size of 500 (while expecting receipt of messages from 251 correct nodes), for a failure rate of $10^{-6}$ a single node has to send > 6Mb of data for a 1Mb of actual data. Though 5x overhead is large, it still prevent us from sending/receiving 500 Mb of data in return for a failure probability of 1 proposal out of 1 million. From the protocol perspective, we can address EC failures in multiple ways: a: Since the root committee only forwards the coded chunks only when they have successfully rebuilt the block. This means the root committee can be contacted to download additional coded chunks to decode the block. b: We allow this failure and let the leader be replaced but since there is proof that the failure is due to the reason that a decoder failed to reconstruct the block, therefore, the leader cannot be punished (if we chose to employ punishment in PoS). 
+
+#### Who sends the signatures up from a given committee? Do that have any leadered power within the committee? - Tanguy
+> Each node in a committee multicasts its vote to all members of the parent committee. Since the size of the vote is small the bit complexity will be low. Introducing a leader within each committee will create a single point of failure within each committee. This is why we avoid maintaining a leader within each committee
+
+#### How much data should a given block be. Are there limits on this and if so, what are they and what do they depend on? - Dmitriy
+> This question can be answered during simulations and experiments over links of different bandwidths and latencies. We will test the protocol performances with different block sizes. As we know increasing the block size results in increased throughput as well as latency. What is the most appropriate block size can be determined once we observe the tradeoff between throughput vs latency.
+
+#### What is our expected minimum number of nodes within the network? - Dmitriy
+> For a small number of nodes we can have just a single committee. But I am not sure how many nodes will join our network 
+
+#### Can we also consider a flavor that adds attestation/attribution to misbehaving nodes? That will come at a price but there might be a set of use cases which would like to have lower performance with strong attribution. Not saying that it must be part of the initial design, but can be think-through/added later. - Marcin
+> [name=Moh]Attestation to misbehaving nodes is part of this protocol. For example, if a node sends an incorrect vote or if a leader proposes an invalid transaction, then this proof will be shared with the network to punish the misbehaving nodes (Though currently this is not part of pseudocode). But it is not possible to reliably prove the attestation of not participation.
+> [name=Marcin] Great, and definitely, we cannot attest that a node was not participating - I was not suggesting that;). But we can also think about extending the attestation for lazy-participants case (if it’s not already part of the protocol).
+> [name=Moh] OK, thanks for the clarification 😁 . Of course we can have this feature to forward the proof of participation of successor committees. In the first version of LogosBFT we had this feature as a sliding window. One could choose the size of the window (in terms of tree levels) for which a node should forward the proof of participation. In the most recent version the size of sliding window is 0. And it is 1 for the root committee. It means root committee members have to forward the proof of participation of their child committee members. Since I was able to prove protocol correctness without forwarding the proofs so we avoid it. But it can be part of the protocol without any significant changes in the protocol
+> [name=Moh] If the proof scheme is efficient ( as the results you presented) in practice and the cost of creating and verifying proofs is not significant then actually adding proofs can be good. But not required.
+
+#### Also, how do you reward online validators / punish offline ones if you can't prove at the block level that someone attested or not? - Tanguy
+> [name=Moh] This is very tricky and so far no one has done it right (to my knowledge). Current reward mechanism for attestation, favours fast nodes.This means if malicious nodes in the network are fast, they can increase their stake in the network faster than the honest nodes and eventually take control of the network. Or in the case of Ethereum a Byzantine leader can include signature of malicious nodes more frequently in the proof of attestation, hence malicious nodes will be rewarded more frequently. Also let me add that I don't have definite answer to your question currently, but I think by revising the protocol assumptions, incentive mechanism and using a game theoretical approach this problem can be resolved.
+> An honest node should wait for a specific number of children votes (to make sure everyone is voting on the same proposal) before voting but does not need to provide any cryptographic proof. Though we build a threshold signature from root committee members and it’s children but not from the whole tree. As long as enough number of nodes follow the the protocol we should be fine. I am working on protocol proofs. Also I think bugs should be discovered during development and testing phase. Changing protocol to detect potential bug might not be a good practice.
+

content/roadmap/consensus/candidates/logos-bft/overview.md

@@ -3,14 +3,16 @@ title: "Logos BFT Overview"
 tags:
   - "consensus"
   - "candidate"
+  - "LogosBFT"
 editor: "Corey Petty"
 ---
 
 Logos BFT is a [consensus](/consensus/index.md) candidate for the Logos Network that utilizes [Network Coding](https://en.wikipedia.org/wiki/Linear_network_coding) and [Committees](#) to optimize message propagation in the presence of a large number of nodes, while maintaining a high level of security. 
 
+- [FAQ](roadmap/consensus/candidates/logos-bft/FAQ.md): Here is a page that tracks various questions people have around LogosBFT.
+
 ## Work Streams
 - [Committee Formation](committee-formation.md)
 - [Random Beacon](random-beacon.md)
 - [Message Dissemination](message-dissemination.md)
 - [Leader Election](leader-election.md)
-- []

content/roadmap/virtual-machines/overview.md

@@ -0,0 +1,63 @@
+---
+titles: "Virtual Machines Overview"
+tags:
+  - "virtual machines"
+  - "zero knowledge"
+---
+
+## Motivation
+Logos seeks to use a privacy-first virtual machine for transaction execution. We beleive this can only be acheived through zero-knowledge. The majority of current work int he field focuses more towards the aggregation and subsequent verification of transactions. This leads us to explore the researching and development of a privacy-first virtual machine. 
+
+LINK TO APPROPRIATE NETWORK REQUIREMENTS HERE
+
+#### Educational Resources
+- primer on Zero Knowledge Virtual Machines - [link](https://youtu.be/GRFPGJW0hic)
+
+### Implementations:
+- TinyRAM - link
+- CairoVM
+- zkSync
+- Hermes
+- [MIDEN](https://polygon.technology/solutions/polygon-miden/) (Polygon)
+- RISK-0
+	- RISK-0 Rust Starter Repository - [link](https://github.com/risc0/risc0-rust-starter)
+	- targets RISC-V architecture
+	- benefits:
+		- a lot of languages already compile to RISC-V
+	- negatives:
+		- not optimized or EVM where most tooling exists currently
+
+## General Building Blocks of a ZK-VM
+- CPU
+	- modeled with "execution trays"
+- RAM
+	- overhead to look out for
+		- range checks
+		- bitwise operations
+		- hashing
+- Specialized circuits
+- Recursion
+
+## Approaches
+- zk-WASM
+- zk-EVM
+- RISK-0
+	- RISK-0 Rust Starter Repository - [link](https://github.com/risc0/risc0-rust-starter)
+	- targets RISC-V architecture
+	- benefits:
+		- a lot of languages already compile to RISC-V
+	- negatives:
+		- not optimized or EVM where most tooling exists currently
+
+## General workstreams
+- bytecode compiler
+- zero-knowledge circuit design
+- opcode architecture (???)
+- engineering
+- required proof system
+- control flow
+	- MAST (as used in MIDEN)
+
+## Roles
+- [ZK Research Engineer](roles/zero-knowledge-research-engineer.md)
+- Senior Rust Developer

content/roles/rust-developer.md

@@ -0,0 +1,63 @@
+---
+title: "Rust Developer"
+tags:
+  - "role"
+  - "engineering"
+  - "rust"
+---
+
+# Role: Rust Developer
+at Status
+
+Remote, Worldwide
+
+**About Status**
+
+Status is an organization building the tools and infrastructure for the advancement of a secure, private, and open web3. We have been completely distributed since inception. Our team is currently 100+ core contributors strong and welcomes a growing number of community members from all walks of life, scattered all around the globe. We care deeply about open source, and our organizational structure has a minimal hierarchy and no fixed work hours. We believe in working with a high degree of autonomy while supporting the organization's priorities.
+
+**About Logos**
+
+A group of Status Contributors is also involved in a new community lead project, called Logos, and this particular role will enable you to also focus on this project. Logos is a grassroots movement to provide trust-minimized, corruption-resistant governing services and social institutions to underserved citizens. 
+
+Logos’ infrastructure will provide a base for the provisioning of the next-generation of governing services and social institutions - paving the way to economic opportunities for those who need them most, whilst respecting basic human rights through the network’s design.You can read more about Logos here: [in this small handbook](https://github.com/acid-info/public-assets/blob/master/logos-manual.pdf) for mindful readers like yourself.
+
+**Who are we?**
+
+We are the Blockchain Infrastructure Team, and we are building the foundation used by other projects at the [Status Network](https://statusnetwork.com/). We are researching consensus algorithms, Multi-Party Computation techniques, ZKPs and other cutting-edge solutions with the aim to take the blockchain technology to the next level of security, decentralization and scalability for a wide range of use cases. We are currently in a research phase, working with models and simulations. In the near future, we will start implementing the research. You will have the opportunity to participate in developing -and improving- the state of the art of blockchain technologies, as well as turning it into a reality.
+
+**Responsibilities:**
+
+-   Develop and maintenance of internal rust libraries
+-   1st month: comfortable with dev framework, simulation app. Improve python lib?
+-   2th-3th month: Start dev of prototype node services
+
+**Ideally you will have:**
+
+-   “Extensive” Rust experience (Async programming is a must)  
+    Ideally they have some GitHub projects to show
+-   Experience with Python
+-   Strong competency in developing and maintaining complex libraries or applications
+-   Experience in, and passion for, blockchain technology.
+-   A strong alignment to our principles: [https://status.im/about/#our-principles](https://status.im/about/#our-principles)  
+    
+
+**Bonus points if**
+
+-    E.g. Comfortable working remotely and asynchronously
+-    Experience working for an open source organization.  
+-    Peer-to-peer or networking experience
+
+_[Don’t worry if you don’t meet all of these criteria, we’d still love to hear from you anyway if you think you’d be a great fit for this role!]_
+
+**Compensation**
+
+We are happy to pay in either 100% fiat or any mix of fiat and/or crypto. For more information regarding benefits at Status: [https://people-ops.status.im/tag/perks/](https://people-ops.status.im/tag/perks/)
+
+**Hiring Process** 
+
+The hiring process for this role will be:
+
+1.  Interview with Maya (People Ops team)
+2.  Interview with Corey (Logos Program Owner)
+3.  Interview with Daniel (Engineering Lead)
+4.  Interview with Jarrad (Cofounder)

content/roles/zero-knowledge-research-engineer.md

@@ -0,0 +1,79 @@
+---
+title: "Zero Knowledge Research Engineer"
+tags:
+  - "engineering"
+  - "role"
+  - "zero knowledge"
+---
+at Status
+
+Remote, Worldwide
+
+**About Status**
+
+Status is building the tools and infrastructure for the advancement of a secure, private, and open web3. 
+
+With the high level goals of preserving the right to privacy, mitigating the risk of censorship, and promoting economic trade in a transparent, open manner, Status is building a community where anyone is welcome to join and contribute.
+
+As an organization, Status seeks to push the web3 ecosystem forward through research, creation of developer tools, and support of the open source community. 
+
+As a product, Status is an open source, Ethereum-based app that gives users the power to chat, transact, and access a revolutionary world of DApps on the decentralized web. But Status is also building foundational infrastructure for the whole Ethereum ecosystem, including the Nimbus ETH 1.0 and 2.0 clients, the Keycard hardware wallet, and the Waku messaging protocol (a continuation of Whisper).
+
+As a team, Status has been completely distributed since inception.  Our team is currently 100+ core contributors strong, and welcomes a growing number of community members from all walks of life, scattered all around the globe. 
+
+We care deeply about open source, and our organizational structure has minimal hierarchy and no fixed work hours. We believe in working with a high degree of autonomy while supporting the organization's priorities.
+
+**Who are we**
+
+[Vac](http://vac.dev/) **builds** [public good](https://en.wikipedia.org/wiki/Public_good) protocols for the decentralized web.
+
+We do applied research based on which we build protocols, libraries and publications. Custodians of protocols that reflect [a set of principles](http://vac.dev/principles) - liberty, privacy, etc.
+
+You can see a sample of some of our work here: [Vac, Waku v2 and Ethereum Messaging](https://vac.dev/waku-v2-ethereum-messaging), [Privacy-preserving p2p economic spam protection in Waku v2](https://vac.dev/rln-relay), [Waku v2 RFC](https://rfc.vac.dev/spec/10/). Our attitude towards ZK: [Vac <3 ZK](https://forum.vac.dev/t/vac-3-zk/97).
+
+**The role**
+
+This role will be part of a new team that will make a provable and private WASM engine that runs everywhere. As a research engineer, you will be responsible for researching, designing, analyzing and implementing circuits that allow for proving private computation of execution in WASM. This includes having a deep understanding of relevant ZK proof systems and tooling (zk-SNARK, Circom, Plonk/Halo 2, zk-STARK, etc), as well as different architectures (zk-EVM Community Effort, Polygon Hermez and similar) and their trade-offs. You will collaborate with the Vac Research team, and work with requirements from our new Logos program. As one of the first hires of a greenfield project, you are expected to take on significant responsibility,  while collaborating with other research engineers, including compiler engineers and senior Rust engineers.  
+  
+
+**Key responsibilities** 
+
+-   Research, analyze and design proof systems and architectures for private computation
+-   Be familiar and adapt to research needs zero-knowledge circuits written in Rust Design and implement zero-knowledge circuits in Rust
+-   Write specifications and communicate research findings through write-ups
+-   Break down complex problems, and know what can and what can’t be dealt with later
+-   Perform security analysis, measure performance of and debug circuits
+
+**You ideally will have**
+
+-   Very strong academic or engineering background (PhD-level or equivalent in industry); relevant research experience
+-   Experience with low level/strongly typed languages (C/C++/Go/Rust or Java/C#)
+-   Experience with Open Source software
+-   Deep understanding of Zero-Knowledge proof systems (zk-SNARK, circom, Plonk/Halo2, zk-STARK), elliptic curve cryptography, and circuit design
+-   Keen communicator, eager to share your work in a wide variety of contexts, like internal and public presentations, blog posts and academic papers.
+-   Experience in, and passion for, blockchain technology.
+-   A strong alignment to our principles: [https://status.im/about/#our-principles](https://status.im/about/#our-principles)
+
+**Bonus points if** 
+
+-   Experience in provable and/or private computation (zkEVM, other ZK VM)
+-   Rust Zero Knowledge tooling
+-   Experience with WebAssemblyWASM
+
+[Don’t worry if you don’t meet all of these criteria, we’d still love to hear from you anyway if you think you’d be a great fit for this role. Just explain to us why in your cover letter].
+
+**Hiring process** 
+
+The hiring process for this role will be:
+
+1.  Interview with Angel/Maya from our Talent team
+2.  Interview with team member from the Vac team
+3.  Pair programming task with the Vac team
+4.  Interview with Oskar, the Vac team lead
+5.  Interview with Jacek, Program lead
+
+The steps may change along the way if we see it makes sense to adapt the interview stages, so please consider the above as a guideline.
+
+**Compensation**
+
+We are happy to pay in either 100% fiat or any mix of fiat and/or crypto. For more information regarding benefits at Status: [https://people-ops.status.im/tag/perks/](https://people-ops.status.im/tag/perks/)