user7627: In plutus playground, there is an example called “Vesting”. In the simulation, users can interact with this smart contract by click on “vest fund” or “retrieve funds”.
Now suppose that we compile this into a plutus script (Vesting.plutus) and then use cardano-cli (or other tools) to actually deploy this smart contract to the real blockchain.
How would users interact with this real-world smart contract?
To be more specific, here is the hypothetical steps:

User A send a transaction to vest funds to the contract.
User B send another transaction to retrieve funds from the contract.

The two transactions must be different. There must be some kind of parameters to indicate that the transaction is about to vest or retrieve the fund, activating different endpoint specified in the contract.
What is the different between the build of the transaction in step 1 and 2?

user609: As @walker-leite pointed out, you interact with the address of the validator (smart contract).
When user A send a transaction to vest funds to the contract, he actually sends the amount to the address. This is just good old sending some Ada to an address. There is no validator (smart contract) involved here.
The validator is run when the user B wants to retrieve the funds that A sent to the address. This validator code determines if user B can retrieve the funds or not.

user5523: 
How would users interact with this real-world smart contract?

Actually what users interact with is the address of the smart contract, the plutus code (the code that produce the hash/address of the contract) must be attached to the transaction everytime it's used as validator of the given transaction (unless CIP-33 is being used).
Everytime an user needs to interact with the smart contract, they do it using the "address" of the contract, which is the "hash" of the contract code.
There are many libraries and tools that can be used to build transactions, PlutusTx (which Playground uses) is one of them.

What is the different between the build of the transaction in step 1 and 2?

The difference is in the constraints being used, in the step 1 the contract wallet is locking the value in the contract through mustPayToTheScript, in the step 2 the contract wallet is redeeming with collectFromScript.

user5085: You can use cardano serialization lib to write a webapp using react and CSL to build transactions for your vesting contract, like those actions for vesting funds or retrieving funds. These transaction can then be sent to blockfrost and get submitted to a cardano node.
That's how many dApps work. You can also construct the transactions on the server side, send them back to the client to be signed by the user's light wallet and then submit them to your own node. (the architecture is pretty much up to you)

7627: <p>In plutus playground, there is an example called “Vesting”. In the simulation, users can interact with this smart contract by click on “vest fund” or “retrieve funds”.</p>
<p>Now suppose that we compile this into a plutus script (Vesting.plutus) and then use cardano-cli (or other tools) to actually deploy this smart contract to the real blockchain.</p>
<p>How would users interact with this real-world smart contract?</p>
<p>To be more specific, here is the hypothetical steps:</p>
<ol>
<li>User A send a transaction to vest funds to the contract.</li>
<li>User B send another transaction to retrieve funds from the contract.</li>
</ol>
<p>The two transactions must be different. There must be some kind of parameters to indicate that the transaction is about to vest or retrieve the fund, activating different endpoint specified in the contract.</p>
<p>What is the different between the build of the transaction in step 1 and 2?</p>
 609: <p>As @walker-leite pointed out, you interact with the address of the validator (smart contract).</p>
<p>When user A send a transaction to vest funds to the contract, he actually sends the amount to the address. This is just good old sending some Ada to an address. There is no validator (smart contract) involved here.</p>
<p>The validator is run when the user B wants to retrieve the funds that A sent to the address. This validator code determines if user B can retrieve the funds or not.</p>
 5523: <blockquote>
<p>How would users interact with this real-world smart contract?</p>
</blockquote>
<p>Actually what users interact with is the address of the smart contract, the plutus code (the code that produce the hash/address of the contract) must be attached to the transaction everytime it's used as validator of the given transaction (unless <a href="https://developers.cardano.org/docs/governance/cardano-improvement-proposals/CIP-0033" rel="nofollow noreferrer">CIP-33</a> is being used).</p>
<p>Everytime an user needs to interact with the smart contract, they do it using the &quot;address&quot; of the contract, which is the &quot;hash&quot; of the contract code.</p>
<p>There are <a href="https://developers.cardano.org/tools" rel="nofollow noreferrer">many libraries and tools</a> that can be used to build transactions, <a href="https://playground.plutus.iohkdev.io/doc/plutus/tutorials/plutus-tx.html" rel="nofollow noreferrer">PlutusTx</a> (which Playground uses) is one of them.</p>
<blockquote>
<p>What is the different between the build of the transaction in step 1 and 2?</p>
</blockquote>
<p>The difference is in the constraints being used, in the step 1 the contract wallet is locking the value in the contract through <code>mustPayToTheScript</code>, in the step 2 the contract wallet is redeeming with <code>collectFromScript</code>.</p>
 5085: <p>You can use <a href="https://github.com/Emurgo/cardano-serialization-lib" rel="nofollow noreferrer">cardano serialization lib</a> to write a webapp using react and CSL to build transactions for your vesting contract, like those actions for <code>vesting funds</code> or <code>retrieving funds</code>. These transaction can then be sent to <a href="https://blockfrost.io/" rel="nofollow noreferrer">blockfrost</a> and get submitted to a cardano node.
That's how many dApps work. You can also construct the transactions on the server side, send them back to the client to be signed by the user's light wallet and then submit them to your own node. (the architecture is pretty much up to you)</p>
