#Soroban Developers Meeting No.1

40 messages · Page 1 of 1 (latest)

half trail
#

Hi friends! I'm kicking back off a recurring meeting to discuss all things Soroban! As we move towards a stable release for the public network we're moving away from building Soroban itself to building on and with Soroban. To that end I want to ensure there's a space to discuss everything we're learning, common areas where we're getting stuck and for us all to share together as we move towards mainnet.

I'd love to use this thread for folks to pitch:

  • things they'd love to get some clarity on
  • things they're working on and are excited about (dev tools though vs user products)
  • discussion topics they'd like to get the room to think and talk about

We'll meet in https://discord.com/channels/897514728459468821/1159534366712672276 at <t:1696528800:F>

torn skiff
#

Potential discussion point -> can we get expirationLedger on the responses for things like getContractData or getLedgerEntries? At the moment it's v confusing how we are even supposed to know what these values are

half trail
torn skiff
red egret
austere parcel
misty verge
#

I'd like to add a few items for discussion. Multi-Auth, and the ContractSpec "entries". I will post a few examples of what we might need/want.

regal leaf
#

nor do I know how to get the expiration.
how would you use the expiration if you had it?

misty verge
regal leaf
#

hmm, I thought this was about the contract-side access, which didn't seem useful (because you only want to do bumps from the contracts). in terms of the RPC response, sure, it should be available, and I thought it already is available

misty verge
#

As far as multi-auth and soroban-client, I think we need an easier way to do this. In the example below, our sourceAccount is a channel account, which is probably a common occurrence in an enterprise platform.

const SorobanClient = require("soroban-client");

const channelSecret = "";
const adminSecret = "";
const anotherSecret = "";
const contractId = "";

const sourceKp = Keypair.fromSecret(channelSecret);
const adminKp = Keypair.fromSecret(adminSecret);
const anotherKp = Keypair.fromSecret(anotherSecret);

const contract = new SorobanClient.Contract(contractId);
const server = new SorobanClient.Server(
  "https://rpc-futurenet.stellar.org:443"
);

// Get the source account from the ledger
const sourceAccount = await server.getAccount(sourceKp.publicKey());

const authOpNeeded = contract.call(
  "multi_auth",
  new SorobanClient.Address(adminKp.publicKey()).toScVal(),
  new SorobanClient.Address(anotherKp.publicKey()).toScVal()
);

function getSigningKeys(signers) {
  return [adminKp, anotherKp];
}

let tx = new SorobanClient.TransactionBuilder(sourceAccount, {
  fee: SorobanClient.BASE_FEE,
})
  .addOperation(authOpNeeded)
  .setTimeout(30)
  .build();

tx = server.simulateTransaction(tx);

// This is what I think we need a helper for on the SorobanClient
// It could be on the tx object or a static function
const signers = tx.getSigners(tx);

// User supplies the function to get the Keypairs for the signers
const signingKeys = getSigningKeys(signers);

// SorobanClient supplies a function to sign any auths needed for the tx
// either on the tx object or a static function
tx = tx.signAuths(signingKeys);

// Should server.prepareTransaction(tx, SorobanClient.Networks.FUTURENET)
// be called here, after signing the auths?

// We sign with the source Keypair which in our case is a channel account
tx = tx.sign(sourceKp);
// We're good to go

const result = server.sendTransaction(tx);
#

Need these helpers?

/**
 * Returns an array of signers for the given Soroban transaction.
 * The function should traverse the transaction auths and return
 * an array of signers.
 * @param {Object} sorobanTransaction - The Soroban transaction object that should have been simulated
 * @returns {Array} An array of signers for the transaction.  Public keys, not including source.
 */

function getSigners(sorobanTransaction) {}

/**
 * Signs a Soroban transaction auth entries using the provided key pairs.
 * @param {Object} sorobanTransaction - The Soroban transaction to sign.
 * @param {Array} keyPairs - An array of key pairs to use for signing.
 */
function signAuths(sorobanTransaction, keyPairs) {}
#

As for the ContractSpec question, a basic example of where to get the "entries" that are passed to the constructor would be cool.

ionic trench
#

Pretty excited for the event

austere parcel
#

@misty verge what's the benefit of having multi-party auth if a single party controls all of the signing keys? also, wouldn't you want more control about which keys were needed + used for signing? rather than a "here's a buncha private keys, figure it out" approach

radiant whale
#

i want to wrap trustline assets programatically from a contract (possibly using the deployer host function) alternatively i need to do it from soroban-client (wrap the token from my web-app) and need to understand what to do

torn skiff
#

If we have time, would also like to discuss extending the Maximum rent bump: 31 days resource limit for Phase 1

misty verge
regal leaf
#

If we have time, would also like to discuss extending the Maximum rent bump: 31 days resource limit for Phase
yes, this is the one where there is no good reason for a low limit from the safety standpoint (besides way too low fees, which I don't think is likely to be an issue). the motivation for the lower limit is mostly to make everyone care about the rent bumps, but OTOH one still needs to bump entry at least once, which might be good enough (and give more time to come up with a more holistic solution to bumps)

torn skiff
austere parcel
regal leaf
#

let max_exp = env.get_max_expiration_ledger(); env.storage().persistent().bump(key, lower_watermark, max_exp) will do the trick without upgrades

#

also it could be a good idea to make bumps configurable if you're uncertain about the contract interaction patterns

torn skiff
regal leaf
#

well, you can do max(max_expiration_ledger, MAX_BUMP_I_WANT_TO_ALLOW)

#

FWIW I'd also vote for increasing the limit. but patterns like this might be generally useful to prepare for any changes

half trail
#

Great meeting everyone! Thank you for attending. Here are my bullet item takeaways. Am I missing anything?

  • Ensure there’s a mechanic to get a ledger entries expiration ledger
  • Differentiate the status of a ledger entry between “never existed”, “live”, “expired” and “evicted”
  • Provide and expose examples for performing complex multi address auth on Soroban transactions
  • Provide documentation on the Soroban JS SDK ContracSpect
  • Write some docs on and/or continue to improve on bumping entries to the max
  • Increase Phase 1 maximum bump from 1 month to 1 year
regal leaf
#

Increase Phase 1 maximum bump from 1 month to 1 year
I'm not 100% confident on 1 year, maybe 6 months...

torn skiff
radiant whale
#

1 year awesome. 6 months still great 3 months better than 1 month and anything over 1 month is still better than 1 month

regal leaf
#

so 1 month and 5 minutes it is 😛

radiant whale
#

Well thats disappointing but hey its still over 30 days

#

1 year ftw but ill compromise with 6 months. 😆 what is the reason to not make it unlimited? Because the fees work on demand?

regal leaf
#

yes, fees depend on the ledger size, unlimited bumps would defeat the purpose of ledger-dependent fees (or any dynamic fees for that worth)

radiant whale
#

Will trust the issue to your smarter brain. 👌 but for the love of god lets go like 3x the current 1 month limit just make the cost of byte per ledger be higher the more ledgers u wanna bump this will discourage unnecessary bumping ? Idk. Havent thought about the mechanics a ton except to try to minimize what i need to store

regal leaf
#

it's not about unnecessary bumping, it's more so to prevent something like creating an entry today with 16 GB ledger and letting it stay for 5 years and, say, 50 GB ledger. basically, no matter what's the absolute fee now, we want it to grow as the ledger grows (so no matter if it's X now and 4X in 5 years, or it's 2X now and 8X in 5 years)