Remove Narwhal/Tusk FAQ entry (MystenLabs#1259)

* Update faq.md

Remove Narwhal/Tusk FAQ entry
Include it in Objects description in PR MystenLabs#1258

* Update faq.md

Remove Move link from initial list as redundant to portal link immediately above

doc/src/contribute/faq.md

@@ -18,7 +18,6 @@ Use these online resources:
 
 * Sui Website: [https://sui.io/](https://sui.io/)
 * Sui Developer Portal: [https://docs.sui.io/](https://docs.sui.io/)
-* Move Programming Language: [https://docs.sui.io/build/move](../build/move.md)
 * Sui Smart Contract White Paper: [https://github.com/MystenLabs/sui/blob/main/doc/paper/sui.pdf](https://github.com/MystenLabs/sui/blob/main/doc/paper/sui.pdf) 
 * SDK reference: [https://app.swaggerhub.com/apis/MystenLabs/sui-api/](https://app.swaggerhub.com/apis/MystenLabs/sui-api/)  
 
@@ -150,35 +149,9 @@ See [Why move?](../learn/why-move) for more details on this. In addition, see th
 Finally, the EVM developer community is very small--approximately 4,000 programmers according to [this study](https://medium.com/electric-capital/electric-capital-developer-report-2021-f37874efea6d). Compare this to (e.g.) the [>20M registered iOS developers](https://techcrunch.com/2018/06/04/app-store-hits-20m-registered-developers-at-100b-in-revenues-500m-visitors-per-week/#:~:text=Today%20at%20WWDC%2C%20Apple's%20CEO,500%20million%20visitors%20per%20week.). Thus, the practical path to scaling the smart contract dev community is to bring folks in from the broader population, not to pull them from the tiny pool of existing Solidity developers. We think Move is much safer and much more approachable for mainstream programmers than the EVM.
 
 
-### Can you tell me all about Sui’s shared object consensus?
-
-Q: I have been looking into your project since the announcement and have a question about this comment from the white paper:
-
-“When full agreement is required we use a high-throughput DAG-based consensus, e.g. [9] to manage locks, while execution on different shared objects is parallelized.”
-
-The referenced paper is Narwhal and Tusk. I understand that Narwhal enables the parallel ordering of transactions into batches which are collected into concurrently proposed blocks, and that Tusk defines an algorithm for executing the DAG that these blocks form. Is your consensus for shared-object transactions a direct implementation of Narwhal and Tusk, or have you made some modifications to enable the parallel execution of transactions that touch independent sets of shared objects? How do you ensure that the DAG encodes the dependencies between the different sets of objects referenced by each transaction (given that these dependencies may change according to the order that the transactions are executed in)? If the DAG does not encode these dependencies, then how do you identify them? 
-
-For context, I am assuming that Sui-Move allows Smart Contracts to define and modify internal variables (i.e. variables not referenced in the transaction data) and supports conditional flows
-
-A: - Narwhal/Tusk (N/T) builds a DAG of blocks, indeed concurrently proposed, and creates an order between those blocks as a byproduct of the building of the DAG. But that order is overlaid on top of the causal order of Sui transactions (the "payload" of Narwhal/Tusk here), and does not substitute for it.
-
-- Narwhal/Tusk operates in OX, rather than XO mode (O = order, X = execute): the execution occurs after the Narwhal/Tusk ordering.
-
-- The output of N/T is therefore a sequence of transactions, with interdependencies stored in the transaction data itself.
-
-What we sequence using consensus is certificates of transactions. These represent transactions that have already been presented to 2/3 of authorities, that checked that all their owned objects are available to be operated on, and signed the transaction. Upon a certificate being sequenced, what we do is set the "lock" of the shared objects at the next available version to map to the execution of that certificate. So for example if we have a shared object X at version 2, and we sequence certificate T, we store T -> [(X, 2)]. That is all we do synchronously when we reach consensus, and as a result we are able to ingest a lot of sequenced transactions.
-
-Now, once this is done we can process all certificates that had their locks set, on one or multiple cores (currently). Obviously, transactions for earlier versions of objects need to be processed first (causally), and that reduces the degree of concurrency. Both the read and write set is determined by the transaction itself, and not dynamically based on the contents of the object at a specific version (not currently). 
-
-It is an interesting question whether allowing dynamic read / write set inference might bring benefits -- we will have to see the nature of contracts and how they are implemented to understand this better.
-
-
 ### Is there a difference in principle between Solana Sealevel and Sui execution?
-Q:
-
-For transactions involving shared objects, the broad strokes look similar
 
-obviously every Solana transaction would go through the consensus mechanism in Solana
+Q: For transactions involving shared objects, the broad strokes look similar. Obviously, every Solana transaction would go through the consensus mechanism in Solana
 
 A: As far as parallelism goes: