© Santiago Palladino 2019
S. PalladinoEthereum for Web Developershttps://doi.org/10.1007/978-1-4842-5278-9_2

2. A Sample DApp

Santiago Palladino1 
(1)
Ciudad Autónoma de Buenos Aires, Argentina
 

In this chapter, we will build a full DApp from scratch. While we will not be going in-depth on the steps involved, this chapter will help you identify all the components involved in the construction of a decentralized application. In the upcoming chapters, we will focus on each of the different parts, but you can always refer back to these pages to understand how each section fits within the bigger picture.

About Our DApp

We will be creating a global counter implemented as a DApp. Users should be able to view the value of the counter and increase it by sending a transaction to it. Even though this application has no practical uses, it will be of help to go through each of the components of a DApp.

Our Requirements

Our application will hold a single counter as its state, and allow any Ethereum user to increase it through a transaction. At the same time, any user accessing the DApp should be able to see real-time updates to the counter’s value.

The application will not manage any ETH at all and will not have any kind of access control. As long as a user can reach the DApp, they should be able to freely interact with it.

The Smart Contract

Ethereum smart contracts are small programs deployed in the Ethereum blockchain. Every contract has its own code and internal state. In this application, we will store the counter’s value in the contract’s state. The contract will also provide a getter for any client to easily query its value, as well as a method to increase it by sending a transaction to the contract (Listing 2-1).
pragma solidity ^0.5.0;
contract Counter {
    uint256 public value;
    function increase() public {
        value = value + 1;
    }
}
Listing 2-1

Initial implementation of the smart contract backing our sample DApp

The smart contract should also provide an event for clients to listen for real-time updates to its state (Listing 2-2). Every transaction in Ethereum may optionally fire one or more events, and a client can subscribe to a particular set of them, as a means to be notified of any changes to a contract.
pragma solidity ^0.5.0;
contract Counter {
    uint256 public value;
    event Increased(uint256 newValue);
    function increase() public {
        value = value + 1;
        emit Increased(value);
    }
}
Listing 2-2

Updated implementation to emit an event every time the increase method is invoked

Now, this implementation shows all the basic ways in which a smart contract provides an interface for a client to interact with it:

  • A getter to query the internal state of the contract, value. It is autogenerated by the use of the public keyword when declaring the field. Querying a contract is fast and does not involve sending a transaction, and so it does not require gas or even having an Ethereum account.

  • A function to modify the state of the contract, increase. These functions require a transaction to be sent, which require ETH to be executed. As such, they require having a funded account.

  • The Increased event, to listen for updates to the contract state. Any client can request to subscribe to a set of events from a contract, to get notifications of any changes to it.

We will go into detail on smart contracts in the next chapter. For now, these concepts will do in order to build our DApp.

The Architecture

We will build a traditional DApp for this example. The application will be backed by a smart contract in the Ethereum network, which will act as a distributed database for the Dapp’s users. The front-end will be set up as a regular client-side javascript application.

For the glue between the javascript front-end and the Ethereum network, we will rely on a web3-enabled web browser. This is a kind of browser that allows the user to connect not only to the Internet but also to the Ethereum network via a node of their own choice. It also manages the user’s private keys and transaction signing.

The most popular web3-enabled browser is MetaMask,1 which is not a browser per se but a plugin, that provides all the required features. MetaMask keeps track of the user private keys, allows connections to a list of predefined nodes or to a custom one, and prompts the user to accept any transaction that the current page is trying to send on their behalf.

From the developer’s perspective, MetaMask injects a global connection provider to an Ethereum node, and intercepts all transactions for signing them with its own keys.

Setting Up the Environment

Before we start building the DApp, we will set up our development environment, as well as the required tools for interacting with and testing our DApp.

Development Toolchain

The basic setup for our development environment will be the one required to build a simple client-side-only javascript application. Make sure to have nodejs and npm installed2 on your development machine to get started.

We will jumpstart our application by relying on the create-react-app package. This is a package, provided by the Facebook development team, that initializes a new preconfigured React web application. This will allow us to save most of the setup time and focus on building the DApp.
npm init react-app counter-app
As for the Ethereum-specific libraries, while there are many development frameworks available, we will stick to the bare minimum for this example. The only Ethereum-related javascript library we will be using is web3.js.3 This is a library whose development is backed by the Ethereum foundation and is regarded by many as the de facto canonical library.
npm install [email protected]
Regarding the Ethereum build toolchain, we will again focus on the minimum set of tools needed. First we will install the Solidity compiler, in order to compile the smart contracts.4 Make sure you install version 0.5.0 or above.
$ solc ––version
solc, the solidity compiler commandline interface
Version: ...
Then, in order to set up automated tests for our application, we will install ganache. Ganache is a process that exposes a similar interface to an Ethereum node and simulates an entire Ethereum blockchain by itself. It is particularly useful in development environments or for running unit tests.
npm install -g ganache-cli

By default, ganache immediately mines a new block for every transaction sent, eliminating the time to wait until a transaction is confirmed. This makes it easy for using it as a back end while coding, but keep in mind that a ganache environment will be drastically different, especially in terms of user experience, to a real one.

Web3 Browser

We will now set up a web3-enabled browser, using MetaMask. Remember that there are other web3-ready browsers, but at the time of this writing, MetaMask is the most popular way to interact with DApps.

Start out by installing the MetaMask plugin5 for your browser – it supports Chrome, Firefox, Opera, and Brave. After installation, MetaMask will prompt you to create a password to encrypt your accounts and will present you with the secret backup phrase. Make sure to write down this phrase: in the event that you lose your MetaMask wallet, you can regenerate it using this phrase. Otherwise, all funds contained in it will be irremediably lost.

Warning

Be extra careful when installing MetaMask. Most software related to managing user keys or transactions is prone to be subject to phishing attacks. Always ensure you are accessing the official MetaMask site when downloading.

Next step is to actually fund your account in order to interact with smart contracts. For the examples throughout this book, we will be using the Rinkeby test network (or testnet). Ethereum has several testnets (Ropsten, Rinkeby, Kovan, and Goerli), each with its own characteristics and identified by a unique numeric ID:

  • Ropsten (id 3) is the only proof-of-work-based testnet, which makes it the most similar one to mainnet, but is also very unreliable. As there is not much actual work being done on the network, block times are unpredictable, and the network is highly susceptible to attacks.

  • Rinkeby (id 4) is a proof-of-authority-based testnet, which means that there are a set of trusted nodes which have the authority to add new blocks to the blockchain. This makes it much more stable and reliable than Ropsten. However, due to limitations of the consensus algorithm used, only Geth clients can connect to Rinkeby.

  • Kovan (id 42) is similar to Rinkeby, in that it is a proof-of-authority-based testnet, but its consensus algorithm is compatible with Parity clients instead of Geth.

  • Goerli (id 6) is the most recent testnet set up. It uses proof-of-authority as well, with the advantage that it is compatible with both Geth and Parity clients.

There are several online faucets6 to obtain testnet ETH to play around. Use one of them to request funds for one of the accounts you have just created on MetaMask.

Note

How did you find the onboarding process on MetaMask? If you think it was complicated or a bit long, now think of your users. All first-time users to Ethereum need to go through a similar process, with the additional burden of having to sign up in an exchange to purchase real mainnet ETH to interact with your app, which often requires a full KYC process. This is why user onboarding is such a challenge on Ethereum. There are techniques to mitigate this issue, such as not requiring your users to have an Ethereum account until it is absolutely needed, or alternative onboarding flows built on meta transactions. More on this later in Chapter 7!

Building Our Application

We will start building from the create-react-app template. Make sure to have run all the steps on the “Setting up the environment” section, and you should have a simple javascript app with a handful of files under the src folder, built around index.js. To verify that everything is running smoothly, run npm run start and open your browser in localhost:3000. You should see the default initial screen of the create-react-app package, including a rotating React logo.

Compiling the Smart Contract

Our DApp will be backed by a single smart contract, Counter. Create a contracts folder in the root of your project, and add a Counter.sol file (Listing 2-3).
// contracts/Counter.sol
pragma solidity ^0.5.0;
contract Counter {
    uint256 public value;
    event Increased(uint256 newValue);
    function increase() public {
        value = value + 1;
        emit Increased(value);
    }
}
Listing 2-3

Smart contract implementation in Solidity that we will use in our application

We will go more in-depth on smart contracts in the next chapter, but for now you can start identifying the important pieces of the contract:

  • The contract’s state, value, defined as an unsigned integer of 256 bits, the default size in Solidity

  • The getter to access value, generated by the use of the public keyword in the declaration of the field

  • The increase function to increment value via a transaction

  • The Increased event used to signal when a modification of value has occurred

You can test that the contract is fine by running the solidity compiler on it:
$ solc contracts/Counter.sol
Compiler run successful, no output requested.
We need to specify the format in which we want to output the compilation. We are interested especially in the specification of the public interface of the contract, or ABI (Application Binary Interface), which is how our javascript application will communicate with the contract. We also want the binary code, so we can deploy the contract to the network if we need to do so. We can request the Solidity compiler to output these two in a single JSON file we can then use:
solc --pretty-json --combined-json=abi,bin --overwrite
-o ./build/contracts contracts/Counter.sol

Note

The flags needed to output this information from the compiler may change depending on the version you are working with. The preceding code works for Solidity 0.5.1.

The preceding command will generate a file build/contracts/combined.json with all the compilation output. Take a look at it, and we will soon use it to interact with our contract.

Connecting to the Network Via Web3

As mentioned before, we will be using web3.js to connect to the Ethereum network. This requires a web3 provider , which is a small object that knows which node to connect to in order to place calls to smart contracts and send transactions to the network. In other words, as its name implies, the provider provides a connection to an Ethereum node and, from it, to the entire network.

Depending on the library you are working with, the provider is sometimes conflated with the signer. The signer is another component that has the responsibility of signing transactions with the user’s keys, in the case that the keys are not managed by a local node. This is the case for most Dapps, since your average user will not have a node running, but depend on a public one. Because of this, the web3 provider injected by MetaMask acts both as a provider and as a signer. We will review these differences in depth later in the book.

The web3 provider injected by MetaMask can be conveniently accessed from code via Web3.givenProvider. You can check this property to know if MetaMask is enabled in your users’ browser, and to create a new web3 object if available. We can keep this logic in a network.js file in our application (Listing 2-4).
// src/eth/network.js
import Web3 from 'web3';
let web3;
export function getWeb3() {
  if (!web3) {
    web3 = new Web3(Web3.givenProvider);
  }
  return web3;
}
Listing 2-4

Snippet for creating a web3 object using the MetaMask provider. Note that this code will not work if the user does not have MetaMask installed.

The web3 object created has a large number of methods available, most of them under the web3.eth namespace. For instance, we can query the list of the user’s accounts (Listing 2-5) and retrieve the default one in use – which is the first one from the list.
// src/eth/network.js
export async function getAccount() {
  const web3 = getWeb3();
  const accounts = await web3.eth.getAccounts();
  return accounts[0];
}
Listing 2-5

Function for retrieving the user’s current default account

However, this method will not work for browsers that run in privacy mode. Privacy mode restricts accessing to user accounts until the user approves the application to retrieve the accounts held in MetaMask. To unlock this, we must work with a global ethereum object and enable it (Listing 2-6).
export async function getAccount() {
  const accounts = await window.ethereum.enable();
  return accounts[0];
}
Listing 2-6

Function updated to handle Ethereum browsers’ privacy mode

The async call to ethereum.enable will return once the user has granted their approval on MetaMask. Note that MetaMask will remember the user’s approval, so they are prompted to answer only the first time (Figure 2-1).
../images/476252_1_En_2_Chapter/476252_1_En_2_Fig1_HTML.jpg
Figure 2-1

Users must accept the Dapp’s connection request in MetaMask

Now that we have a web3 object set up, as well as access to the user’s accounts, we will use them to build our interface to the Counter smart contract deployed on the Ethereum network.

The Contract Interface

In order to interact with our contract from the application, we need three things:

  • A connection to the Ethereum network where our contract is deployed

  • The address of the contract in the network

  • The specification of the contract’s public functions, also known as the ABI (Application Binary Interface)

The first item is covered in the previous section, and is encapsulated by the web3 object we provisioned. As for the second item, we will use an already deployed instance in the Rinkeby network at the following address:
0x1D2561D18dD2fc204CcC8831026d28375065ed53

Remember that everything in the blockchain is public and indeleble, so once a contract is deployed, it becomes publicly available for all users to interact with and cannot be deleted. This means we can freely use this instance for testing the DApp.

Note

If you do not want to work with that particular contract instance or prefer to work on a different network, there is a deploy script on the code repository that you can use to set up your own instance.

As for the ABI, we will make use of the output generated by the compiler previously. Copy the output json file into an Artifacts.json file in a new contracts folder in your application src. We can now parse it to obtain the ABI, and create a new web3 contract instance (Listing 2-7).
// src/contracts/Counter.js
import Artifacts from './Artifacts.json';
export default function Counter(web3, address, options = {}) {
  const name = "contracts/Counter.sol:Counter";
  const artifact = Artifacts.contracts[name];
  const abi = JSON.parse(artifact.abi);
  return new web3.eth.Contract(abi, address, options);
}
Listing 2-7

Function to create a Counter web3 contract object. Note that the function does not deploy a new contract, it just creates a javascript object that acts as a wrapper to a contract previously deployed at a specified address

The web3 Contract abstraction is an object that acts as a facade for the actual Ethereum contract. It exposes javascript methods for all its public functions, which get translated into calls and transactions to the network under the hood. We will be using it in the following section to actually interact with the contract.

Now that we have our factory-like function that can create new Counter contract abstractions given an address, we will use it to retrieve the deployed contract (Listing 2-8).
// src/contracts/Counter.js
import { getWeb3, getAccount } from '../eth/network.js';
export async function getDeployed() {
  const web3 = getWeb3();
  const from = await getAccount();
  const addr = "0x1D2561D18dD2fc204CcC8831026d28375065ed53";
  return Counter(web3, addr, { from });
}
Listing 2-8

Code for obtaining a web3 contract instance of the Counter contract deployed on the Rinkeby network. Note that, to avoid hard-coding the address, you can also store the address as an environment variable, and retrieve it from process.env7

Now that we have the means to interact with the deployed contract, we can build the React visual component for our user interface.

Interacting with Our Smart Contract

We will now progressively build our Counter visual component to allow the users of our DApp to interact with it. We will begin by retrieving the current value of the counter, then provide a means to send a transaction to modify its state, and then subscribe to real-time updates to it.

Wiring Our Component

Let’s start by creating a file components/Counter.js (Listing 2-9). This will be an empty React component8 for now.
// src/components/Counter.js
import React, { Component } from 'react';
class Counter extends Component {
  render() {
    return (
      <div>Counter be here</div>
    );
  }
}
Listing 2-9

Empty React component for rendering the Counter contract and interacting with it. We will be iteratively adding features to it

This component will receive from the App.js root component the Counter contract instance. It will be the App’s responsibility to retrieve such instance and inject into the Counter visual component once ready. Let’s modify the src/App.js file that was autogenerated by create-react-app to load the contract instance (Listing 2-10).
import './App.css';
import React, { Component } from 'react';
import Counter from './components/Counter';
import { getDeployed } from './contracts/Counter';
class App extends Component {
  state = { counter: null };
  async componentDidMount() {
    const counter = await getDeployed();
    this.setState({ counter });
  }
  render() {
    const { counter } = this.state;
    return (
      <div className="App">
        { counter && <Counter contract={counter} /> }
      </div>
    );
  }
}
export default App;
Listing 2-10

Code for the App root component. We use the root App state to store the contract instance, and pass it to the child component as a property

We are relying on the componentDidMount React event to load the Counter contract instance9 and storing it in the component’s state. Only when this instance is available we render the Counter visual component.

Note

By now, you may have realized that we are missing error management in this DApp. For instance, we are not handling the case where the user does not have MetaMask, or if the contract’s address is incorrect, or if the connection to the network is lost. This is a deliberate decision, as the goal is to focus on the happy path and provide a quick overview of what constitutes a DApp. In the upcoming chapters, as we go deeper into each subject, we will also cover everything that can potentially go wrong.

At this point, you should be able to run your application via npm start and check that everything is rendering correctly. Make sure to have MetaMask installed, unlocked, and connected to the Rinkeby network.

Now that we have all of our application wired, it’s time to focus on the Counter visual component itself.

Querying the Contract’s State

We will begin by displaying the value of the Counter contract on our component (Listing 2-11). Since we will not be changing the Counter instance during the lifetime of our component, we can simply retrieve that value when the React component is mounted.10
// src/components/Counter.js
async componentDidMount() {
  const counter = this.props.contract;
  const initialValue = await counter.methods.value().call();
  this.setState({ value: initialValue });
}
Listing 2-11

Retrieving the initial value of the Counter when the component is mounted

Note the call to the counter contract instance to retrieve the initial value. The web3js API for the call may seem awkward, but it has a rationale behind it:

  • The methods property grants access to all the public methods defined in the contract’s ABI. They are not set at the contract instance itself, to prevent clashing with other methods specific to the web3 contract object.

  • The value() call does not actually query the network, but simply builds a method call. If the function required any parameters, they would have to be supplied here.

  • The call() invocation finally issues the query to the blockchain. We will review in the next chapter the difference between querying a method and issuing a transaction, but for now, all we need to know is that call() is used when we want to retrieve data from a contract.

Once we have set the initial value in the component’s state, we can finally render it to our users (Listing 2-12).
render() {
  const { value } = this.state;
  if (!value) return "Loading";
  return (
    <div>
      <div>Counter value: { value.toString() }</div>
    </div>
  );
}
Listing 2-12

Render method to display the counter’s value. Note that the value is only available after the initial query to the contract returns, so we need to handle the case where the value is not yet at our disposal

By this point, you should be able to reload your application in your browser and see the value of the Counter instance on the Rinkeby network.

Tip

You can double-check the value displayed against the one reported by a blockchain explorer, such as Etherscan.11 Etherscan is a blockchain explorer, a web site that provides a visual interface to addresses and transactions, and is available for mainnet and most test networks. Look for the address of the contract, and under the Read Contract tab, you will be able to check the value of the counter.

Our next step will be to allow the user to increase the value of the counter, by issuing a transaction.

Sending a Transaction

Let’s start by writing a function to send a transaction to call the increase function on the Counter contract.
increaseCounter() {
  const counter = this.props.contract;
  return counter.methods.increase().send();
}

After the previous section, the call to send the transaction should be more familiar. Note that in this case we are using send() instead of call(). This is because we need to actually send a transaction to affect the contract’s state, instead of just querying data from the network.

We can now wire this method to a button in our interface (Listing 2-13), and test it.
render() {
  const { value } = this.state;
  if (!value) return "Loading";
  return (
    <div>
      <div>Counter value: { value.toString() }</div>
      <button onClick={() => this.increaseCounter()}>
        Increase counter
      </button>
    </div>
  );
}
Listing 2-13

Updated render method to display a button that increases the counter

If you try this, you will be greeted with Metamask’s dialog to confirm a transaction, which should look more or less like Figure 2-2.
../images/476252_1_En_2_Chapter/476252_1_En_2_Fig2_HTML.jpg
Figure 2-2

Metamask confirmation dialog to accept a transaction issued by the application. Your users will be shown this dialog every time you try to send a transaction on their behalf

If you refresh the page a few seconds after confirming the transaction, you should see the new value of the counter. However, to avoid requiring a page reload to update the value, we will query the value again after the transaction is confirmed (Listing 2-14).
increaseCounter() {
  const counter = this.props.contract;
  return counter.methods.increase().send()
    .on('receipt', async () => {
      const value = await counter.methods.value().call();
      this.setState({ value });
    });
}
Listing 2-14

Query the counter’s value after the transaction is mined

The send() method returns an event emitter, which allows us to listen for different events in the lifetime of a transaction. For now, we are interested only on the event when the transaction is mined, that is, included in a block in the chain. This event is referred to as receipt, since it corresponds to when the transaction receipt object is available. If we wanted, we could also check when the transaction was actually sent to a node, or when it has reached a reasonable number of confirmations.

Now, even if the updated code does refresh the counter’s value, we need to let the user know what is going on. The transaction’s confirmation takes several seconds, which is definitely more than what a regular web 2.0 application usually takes.

We will track the transaction state (Listing 2-15) to show a simple “Awaiting transaction” message to let the user know what is going on, and disable the button in the meantime (Listing 2-16). We will also handle the case in which the transaction fails, so we don’t disable the button permanently. Of course, in a real DApp, you may want to provide better visual cues.
increaseCounter() {
  const counter  = this.props.contract;
  this.setState({ increasing: true, error: null });
  return counter.methods.increase().send()
    .on('receipt', async () => {
      const value = await counter.methods.value().call();
      this.setState({ value, increasing: false });
    })
    .on('error', (error) => {
      this.setState({ error, increasing: false })
    });
}
Listing 2-15

Updated increaseCounter function to keep track of a flag to identify pending transactions and any error returned

render() {
  const { value, increasing, error } = this.state;
  if (!value) return "Loading";
  return (
    <div className="Counter">
      <div>Counter value: { value.toString() }</div>
      <button
        disabled={!!increasing}
        onClick={() => this.increaseCounter()}>
          Increase counter
      </button>
      <div>{ increasing && "Awaiting transaction" }</div>
      <div>{ error && error.message }</div>
    </div>
  );
}
Listing 2-16

Updated render method to display a notification when a transaction is pending or has failed, and disable the button until the transaction is finished

Note

As an alternative to waiting for the transaction to be mined, we could also optimistically update the value. An optimistic update is a technique, used in many asynchronous applications beyond DApps, that consists in assuming that a transaction performed by the user will succeed and immediately updating the value client-side. This way, the user perceives that the application reacts almost instantly and can keep interacting with it and has immediate feedback on the result of their actions.

While this solution is good enough for a single user interacting with a contract, it falls short when there are multiple users involved. You can try this out by opening the web site from two different browser windows: any changes made in one window will not affect the other, unless the contract is queried again by reloading the page. To solve this issue, we will rely on the last concept we introduced in the contract’s interface: events.

Monitoring Updates Via Events

A contract’s public interface is not just composed of public functions. A contract may also emit custom events upon certain transactions. Our Counter contract emits an event named Increased every time the increase function is called, and includes the new value of the counter as an argument.

To monitor all instances of this event, we will subscribe to it when the component mounts and update the component state accordingly (Listing 2-17).
async componentDidMount() {
  const counter = this.props.contract;
  const initialValue = await counter.methods.value().call();
  this.setState({ value: initialValue });
  counter.events.Increased()
    .on('data', (event) => {
      const value = event.returnValues.newValue;
      this.setState({ value });
    });
}
Listing 2-17

Subscription to the Increased event, which updates the component’s state whenever a new instance of the event is emitted

Note that here we are referring to the counter.events property instead of to the counter.methods like we did before. Here, the event emitter fires a data event every time a new event is found, and includes the arguments of the event.

Also, by updating the component’s state on every event, we no longer need to query the contract state whenever a transaction is confirmed. The receipt event handler on the increaseCounter function can be simplified to the following.
    .on('receipt', async () => {
      this.setState({ increasing: false });
    })

With this new setup, you can now receive real-time updates on a contract, regardless of where the state change originated from. Try again opening two browser windows and increasing the counter from one of them, and see how the change is reflected on both of them once the transaction is confirmed. And if you are lucky, you may even stumble upon a change issued by another reader of this book on the same contract instance.

Deploying the Application

As you may have noticed, our sample application runs exclusively client-side. All logic takes place on the browser, and the blockchain is used as a back end to perform simple computations and persist a shared state among all users, acting as a consensus layer on the state of the counter. This makes deployment straightforward, since the DApp needs only to be hosted as a static site.

Summary

In this chapter, we have gone through the process of developing a simple DApp, providing our users with a basic web-based interface for a single smart contract. We have explored how to read state from a contract and send transactions to it and how to monitor events for real-time updates.

We have built our entire application relying on just two libraries: web3js for interacting with the Ethereum network and React as a presentation framework. Given the pace at which libraries and frameworks change in both the javascript and the Ethereum ecosystems, the goal has been (and will be throughout this book) to use as few dependencies as possible and focus on the concepts behind building a DApp instead of on the specific APIs of the tools of the moment. Of course, this does not mean that you should not rely on such tools when building your own DApp, since they may be of great help. Make sure to check out OpenZeppelin, Truffle, Buidler, Etherlime, Embark, Clevis, and whatever is available by the time this book reaches your hands.

All in all, this chapter should have helped as an overview to the entire development process and components of a DApp. We have glossed over the deployments of the contracts themselves, as well as account and ETH management in general. We have not covered many edge cases or error situations that arise when dealing with a blockchain-based back end. Nevertheless, throughout the book, we will go in-depth in all these topics, plus new and more advanced ones, and revisit each step the building of a DApp on more interesting examples.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.140.198.173