---
tags: nc-programs
title: NEAR Certified Developer - FAQ
description: This is a list of questions asked by students and answered here in no particular order
image: https://near.org/wp-content/themes/near-19/assets/downloads/near_logo.svg
GA: UA-188414449-3
---

# NCD Frequently Asked Questions

:::info
## :notebook: NEAR Certified Developer Course
:::

### Are the meetings recorded?

Yes, there are [recordings for each cohort](https://hackmd.io/@nearly-learning/ncd#Recordings).

### What will we learn in a week?

The course is an opportunity for web developers to earn a Certificate of Completion that represents the ability to design, develop, test and deploy smart contracts on the NEAR platform.

During this course we practice the following:

- perceiving web 3 in the context of human history
- reading contract code in Rust and AssemblyScript
- writing contracts using Rust and AssemblyScript
- testing contracts using unit and simulation tests
- deploying contracts and a sensible user interface

The course includes lots of listening, watching, reading and writing. A minimum of 2 hours per day is recommended but up to 4-6 hours per day is likely, especially for developers with less than three years web development experience.

The entire contents of the course is available here: https://hackmd.io/@nearly-learning/ncd

### What will we submit at the end of the week?

Each group will submit a project that is structured like this example: [NEARly Neighbors](https://learn-near.github.io/sample--nearly-neighbors)

The project must include the following elements:

- contract source code (Rust, AssemblyScript or both)
- unit tests, all passing
- simulation tests, all passing
- mockups (frontend UX), but no working frontend is required
- documentation (build, run tests, etc) to help others learn from your work

If you want a specific example of all of this, please refer to *NEARly Neighbors* linked above.

### How many people form a group?

Groups should be 3-5 people. They should be in similar (or same) timezone for more convenient collaboration.

### What is the difference between NCD.L1 vs NCD.L1v?

NCD certification for Level 1 (L1) has 2 components:
- **NCD.L1** certified participants -- members of this group attend one week of NCD and participate in building and demo to receive a "certificate of completion"
- **NCD.L1v** verified developers -- members of this group complete NCD. l1 and pass a 60 minute technical interview to receive a "certificate of verification"

NCD.L1 is a signal of your intention to learn and your commitment to the 5-day program from Kickoff to Demo.

NCD.L1v is a verifiable record of evidence that you have understood the material and are able to apply it to the design, development, testing and deployment of NEAR Smart Contracts

To earn an **L1v**, participants must first complete the standard NCD L1 course with a demo and then schedule a 60 minute paired technical interview with a verification specialist.

The verification session will include at least some of following activities at the discretion of the verifier:

- **Explaining** a working contract
- Reasoning about the behavior of a contract (core contracts, learn-near examples, etc.)
- Predicting the effect of a change in the contract
- Creating a guide to using the contract (NEAR CLI commands, API calls, etc.)
- **Troubleshooting** a broken contract
- Fixing a compilation error
- Fixing a failing unit test
- Fixing a failing simulation test
- Fixing a runtime error (contract logic, interface or other issues)
- **Improving** a working contract
- Refactoring the contract
- Enhancing an existing feature
- Adding a new feature
- Optimizing the contract (size, speed, storage, etc)
- **Creating** a new contract
- Translating an existing contract from AssemblyScript to Rust or vice versa
- Designing a new contract as an improvement to an existing one
- Designing an entirely new contract based on requirements (to be provided by verifier)
- Designing an entirely new contract based an original idea (either their own or the verifier’s idea)

The outcome of a verification session will be one of either: (a) Verified or (b) Unverified

If you do not pass the verification interview, you may reschedule the session 1 time (max 2 attempts) before being waitlisted for 180 days.

### Is it possible to jump straight to L3 certification in case one already has a running dApp?

The key question here could be "why get certified at all?" since certification is a signal that a developer would use to communicate understanding to others like potential investors, co-founders and employers.

In other words, if you successfully launched Instagram last year, there's no need to get a JavaScript Developer Certification to prove that you did it.

If for some reason you want a certification then I'm sure we can accommodate you.

:::info
## :notebook: NEAR Protocol
:::

### How does NEAR compare with Ethereum 2.0?

NEAR and Ethereum 2.0 are solving similar challenges: high transaction costs, scalability, and throughput. They are also taking similar approaches in some ways, but very different in other ways.

- Check out [NEAR 102: Intro to NEAR for Ethereum Developers](https://bit.ly/near-102) (November 2020)
- Check out [Alex Skidanov and Justin Drake re: NEAR vs Ethereum 2.0](https://www.youtube.com/watch?v=8xpOUqdoyp0&list=PL9tzQn_TEuFWweVbfTbaedFdwVrvaYPq4&index=33&ab_channel=NEAR) (April 2020)
- Check out [Why doesn't NEAR just replicate Ethereum Serenity design?](https://medium.com/nearprotocol/why-doesnt-near-just-replicate-ethereum-serenity-design-3e2cfa2f960c) (November 2018)

### What's the consensus algorithm used in NEAR?

> _The consensus mechanism implemented on NEAR is called Nightshade. Nightshade models the system as a single blockchain. The list of all the transactions in each block is split into physical chunks, one chunk per shard. All chunks accumulate to one block. Note that chunks can only be validated by nodes that maintain the state of that shard._
>
> _Theoretically, each logical block contains all the transactions for all the shards. However, since transmitting a logical block across the network would be prohibitively expensive, it is never initiated. Instead, each network participant maintains the state that corresponds to the shards that they validate transactions for and any additional shard that they want to track._
>
> _The consensus is based on the heaviest chain consensus. Meaning, once a block producer publishes a block, they collect the signatures of validator nodes. The weight of a block is then the cumulative stake of all the signers whose signatures are included in the block. The weight of a chain is the sum of the block weights. Additionally, the consensus utilises a finality gadget that introduces additional slashing conditions for higher chain security._
>
> _For more information on security, cross-shard communication, and validation roles, please refer to the Nightshade Paper or our summary in the docs._
>
> _-- Source: [Layer 1 Platform Overview](https://near.org/platforms/)_

Also related:

- Check out NEAR Protocol [consensus specification](https://nomicon.io/ChainSpec/Consensus.html)
- Check out the [Nightshade Whitepaper](https://near.org/downloads/Nightshade.pdf)
- Check out other [papers and articles](https://docs.near.org/docs/concepts/architecture/papers)

### What does the wallet look like?

NEAR Wallet is a non-custodial web-based wallet. It supports several methods for controlling your private keys including:
- Browser `localstorage` (this is the most convenient for you but also least secure)
- Ledger (this is the least convenient for you but also most secure)
- account recovery using email, phone or controlling the seed phrase directly

You can find out more about the NEAR Wallet here:
- [create a TestNet account](https://wallet.testnet.near.org) or follow a [guided walkthrough](https://docs.near.org/docs/develop/basics/create-account)
- read [docs.near.org](https://docs.near.org/docs/tools/near-wallet)
- [fund an account](http://nearnames.com) for a friend
- read the [wallet source code](https://github.com/near/near-wallet)
- check out an alternative: [Narwallet](https://github.com/Narwallets/narwallets-extension)

### Is 2FA centralized?

NEAR Wallet currently supports 2-factor-authentication by deploying a contract to your account. There are currently plans to change this approach.

### What is the TPS of NEAR?

NEAR currently supports up to 200 TPS per shard. This number is rising quickly as the team turns their focus to performance. You can find out more about [high level facts about NEAR here](https://docs.google.com/document/d/1fG3PNTKw727Z5SVyUbJ2nnxn5MZNSGYEZIU2Y7XtlYY)

:::info
## :notebook: Accounts
:::

### Is my account and my contract the same address?

Yes, that's right. NEAR uses human-readable account names. You can deploy one contract to an account if you have a `FullAccess` key on the account. Accounts also have subaccounts which would be useful for creating user accounts under your dApp, for example, or an account for each member of your family under your family name. You can read more about NEAR accounts in our [platform specification](https://nomicon.io/DataStructures/Account.html), [developer docs](https://docs.near.org/docs/concepts/account) and [video walkthroughs](https://docs.near.org/docs/videos/accounts-keys).

### Can I hide my implicit account transactions?

All transactions on NEAR are public. There is a [Cypherpunk Guild](https://gov.near.org/t/cypherpunk-guild-100k-near-seed-funding-for-18-months-approved/692?u=amgando) currently working on introducing private transactions on NEAR and improving privacy on web3 in general

### What does it mean to say "accounts are distributed among shards"?

Although NEAR MainNet is currently running on a single shard, the plan is to upgrade to a mulit-sharded network before 2022. On a multi-sharded system, accounts must be allocated to one and only one shard among many. Developers may want to choose the "best shard" because it's close to other accounts they depend on. NEAR Protocol does not allow this.

Instead, the protocol reserves the right to move accounts around, or "redistribute" them, to maintain network performance. If one account becomes very popular, it may be moved to it's own shard, for example.

:::info
## :notebook: Access Keys
:::

### Are `FullAccess` and `FunctionCall` access keys stored on chain?

Each account holds its own keys in it's storage. These are the _public keys_, of course, while the private keys remain with the users or developers.

### Can I pay gas for the user?

Yes, NEAR supports paying for user onboarding using `FunctionCall` access keys.

There are a few examples of how this can be done in the [NEAR Live App Review](https://youtube.com/playlist?list=PL9tzQn_TEuFXnHlfh00etU57IjpRlQGpY) playlist.

:::info
## :notebook: Contracts
:::

### What contract languages does NEAR support?

NEAR currently supports 2 languages: AssemblyScript and Rust. NEAR also intends to support many more languages like C++, C# and Go as can be seen on the list of [suggestions for grant proposals](https://gov.near.org/t/development-dashboard-apps-catalogue-grant-ideas-wiki/690)

A high level comparison of the pros and cons of each language is included in the [March 8th kickoff](https://hackmd.io/@nearly-learning/ncd#Recordings) slides and recording. Here is the slide again.


Generally speaking, a contract written in AssemblyScript will be smaller than the same contract written in Rust, but the Rust contract will be safer (less likely to have surprising behavior, bugs, etc).

Both Rust and AssemblyScript contracts compile to Wasm so the only differences in contract features are conveniences in the SDKs. The Rust SDK [`near-sdk-rs`](https://github.com/near/near-sdk-rs) is more mature than the AssemblyScript SDK [`near-sdk-as`](https://github.com/near/near-sdk-as). The NEAR team and community try to maintain feature and syntax parity (same features, same words) among SDKs so you should expect to see these two SDKs, and others that come later, all provide the same benefits for developers.

NEAR does not currently teach Rust nor AssemblyScript programming but we are considering running courses for both languages. If you know of anyone interested in these courses, either as a student or teacher (!), please ask them to reach out to us on [Discord](https://near.chat).

### What's the main difference between AssemblyScript and Rust Contracts?

The NEAR Runtime executes compiled Wasm. Since both AssemblyScript and Rust compile to Wasm, there is not technical limitation on what is possible with either language.

Practically speaking, Rust is a far more mature language and ecosystem and the Rust toolchain that developers use to write, debug, test and compile Rust code to Wasm is the best in the industry. In this way, NEAR recommends using Rust for high value contracts including those that manage valuable assets like NFTs or financial applications.

From a learning perspective, both languages communicate with the NEAR Runtime using the same register-based interface so the lessons learned while writing contracts are the same. The Rust sdk (`near-sdk-rs`) does have a few conveniences like being able to mark a method as `#[payable]` which will allow users to attached a deposit (otherwise all methods throw by default if a deposit is attached). The exact same functionality can be introduced to an AssemblyScript contract with a single line of code but some developers prefer the expressiveness of built-in macros for readability.

The key point to understand here is that, if you're just starting to learn NEAR, it doesn't matter which language you choose _as long as the language does NOT add more to your learning workload_. Our recommendation is to focus on the contract language that is easiest for you to understand, learn to write contracts for the NEAR platform then reconsider your language choice for production-grade applications if necessary.

### How much does a typical contract call cost?

There is no such thing as a "typical contract call" but it would be useful to look at historical average costs for contract calls on the platform. Developers usually attach about `5 Tgas` (~ 5 milliseconds of compute time) for single function calls and up to `20 Tgas` for cross-contract calls because of the machinery to broadcast the receipts across the network and spin up another contract.

The best place to look for these kinds of estimates is among our [Core Contracts](https://github.com/near/core-contracts/blob/master/lockup/src/gas.rs).

### Why is a smart contract function call limited to 200ms?

NEAR Protocol is designed for fast block times of about 1 second per block and fast finality of about 2 seconds. Each function call must be limited to 200 ms (200 Tgas) to allow for the overhead of cross-contract calls (up to an additional 300 Tgas allowable for generating cross-contract calls) and the overhead of network communications to arrive at consensus.

It's useful to keep in mind that if function calls were allowed to run for longer than 200 ms then this would increase the necessary block time to arrive at consensus about what happened during the execution of a function.

If you need more than 200 ms to complete an operation then you must break the operation down into multiple-cross contract calls. Have a look at this [merge sort example](https://github.com/near/near-sdk-rs/blob/master/examples/cross-contract-high-level/src/lib.rs#L66) in `near-sdk-rs` for instance.

### Can AssemblyScript contracts interact with Rust contracts?

Absolutely yes. Contracts are compiled to Wasm and executed by the NEAR Runtime. The runtime does not care what technology was used to develop the contract, whether AssemblyScript, Rust or some new contract development language.

From the contract's perspective, you're just calling another contract. You don't care which technology was used to implement it.

:::info
## :notebook: Use Cases
:::

### How do I get a grant？

Visit [**near.org / grants**](https://near.org/grants)

> _The NEAR Grants Program (NGP), directed by the NEAR Foundation, provides funding and resources to expand the NEAR ecosystem._
>
> _The program supports projects that share NEAR’s mission: to accelerate the world’s transition to open technologies by growing and enabling a community of developers and creators._
>
> _In the first half of 2021, the NEAR Grants Pilot Program will award $1 million (USD equivalent) in grants funding and resources to promising teams whose work will foster and expand NEAR’s technology and community._


### Can NEAR be used in game product scenarios?

Absolutely, NEAR is a smart contract platform and can be used to track any data or compute.

There are several groups thinking about building games on NEAR but one new kind of game is a prediction market created by [Flux](https://www.fluxprotocol.org/use-cases).

:::info
## :notebook: General Questions
:::

### What's a "unit test"?

Testing is an important part of software development for a few reasons:

- tests help to prevent "regression errors" where changes you will make tomorrow break things you build today
- tests help focus the development process so developers don't build more than they need to (see test-driven development or [TDD](https://www.agilealliance.org/glossary/tdd/))
- tests give developers confidence in the code they write

### Are the testing steps meant to collect errors or just to step the developing process?

Writing tests as part of the demo is important to help others understand how your code works and to verify that it works as expected.